WCAG SC 2.5.3 requires that labels for user interface components, whether text or images of text, match their programmatically determined names or their prefixes. This ensures uninterrupted access for speech input users and other assistive technology users who rely on viewing the label to access its corresponding control.
To ensure the visible text label of a user interface component matches its accessible name or its prefix.
The accessible name refers to the programmatically determined name assigned to a control, which can be specified using <label>, aria-label, aria-labelledby, alt, or the title attribute, with varying levels of specificity (e.g., aria-label being the most specific). It is crucial for users of speech-to-text assistive technology, who rely on matching visible labels to operate controls without interruption. Failure to match the visible label with the accessible name or its prefix prevents users from effectively interacting with controls.
Authors may provide additional text or hints for users with cognitive or visual disabilities, which are hidden from sighted users (e.g., using a hidden <span>, aria-labelledby, or aria-label that overrides the accessible name but should still match the label's prefix). It is essential that the label at least matches the prefix of the accessible name. For example, if the label is 'Search', the accessible name could be extended to 'Search for shoes' by adding aria-label attribute, to provide additional information for visually impaired users while still matching the prefix 'Search'. Notably, there is no requirement for uppercase letters to match for this criterion.
Choosing a different accessible name such as 'Shoes could be searched here' would fail to meet this criterion, as speech-to-text assistive technologies would not correctly identify the control.
Ensure matching visible and programmatic labels: Ensure the visible label text matches its programmatic name or prefix, such as aria-label or alt attribute. Place the visible label text at the beginning of the accessible name.
Avoid symbols as labels: Avoid using symbols as labels to prevent inaccuracies, unless essential. For example, essential symbols like mathematical signs (e.g., the 'times' sign) should be used with their HTML character entity, such as ×, to ensure accuracy for speech-to-text assistive technologies.
Provide individual and group labels for radiogroups and checkboxes: For radiogroups and checkboxes, provide each option with its own label, and assign a common label to the entire group using <fieldset> and <legend> or the ARIA roles role="radiogroup" or role="group". This approach prevents screen reader users from hearing the same comment for each radio button or checkbox and increases accuracy for speech-to-text users.
Example: A Button's Visible and Accessible Names
<button aria-label="Buy new shoes">Purchase</button>
Explanation:A webpage contains a button with a visible label that says "Purchase” , but the aria-label for the button says "Buy new shoes." In this incorrect implementation, speech input users who say "Purchase" might not be able to activate the button because the programmatic accessible name ("Buy new shoes") does not match the visible label ("Purchase").
<button aria-label="Purchase new shoes">Purchase</button>
Explanation:In the correct implementation, we ensured that the prefix of the accessible name of the control 'Purchase new shoes' matches the visible label of the button 'Purchase'. This ensures that both screen reader users perceive the purpose of the control, meeting success criterion 1.3.1 (information and relationship), and allows speech-to-text assistive technology users to operate the control by announcing 'Purchase' as the visible name, meeting success criterion 2.5.3.