Loading...
Loading content...
Loading content...
The accessible name (for screen readers) must match the visible label.
Why it matters: Speech recognition users say the visible label to interact. If the code name is different, it won't work.
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
What This Means: This success criterion requires that the accessible name (the name used by assistive technologies like screen readers and speech recognition) must contain the visible label text. The accessible name can include additional text, but it must start with or contain the visible label.
Why It's Important: Users of speech recognition software see the visible label and speak it to interact with elements. If the accessible name doesn't match what they see, speech recognition won't work. For example, if a button shows 'Submit Form' but the accessible name is 'Send', users saying 'Submit Form' won't activate it. This creates a barrier for users who rely on speech recognition.
When using aria-label, ensure it contains the visible text. For icon-only buttons, the accessible name should match what users would naturally say to activate it. The visible label text should appear at the start of the accessible name. If using aria-labelledby, ensure the referenced text matches the visible label.
This criterion ensures that speech recognition users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that screen reader users can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
Button shows 'Submit Form' but accessible name is 'Send', so speech recognition fails.
<button aria-label="Send">Submit Form</button>Button shows 'Submit Form' and accessible name is 'Submit Form', so speech recognition works.
<button>Submit Form</button>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 2.5.3 Label in Name are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If I use aria-label, I don't need to worry about visible text.
aria-label should contain the visible text. Speech recognition users see and say the visible text, so the accessible name must match it.
The accessible name can be completely different from the visible label.
The accessible name must contain the visible label text. It can have additional text, but must start with or include the visible label.
Icon buttons with aria-label that doesn't match visible context.
Ensure aria-label includes text that matches what users see. For example, if button shows 'X' to close, aria-label should be 'Close' or 'Close dialog', not just 'X'.
Buttons where visible text and accessible name are different.
Make accessible name contain the visible text. Use visible text as the primary label, or ensure aria-label starts with visible text.
Form labels that don't match accessible names.
Ensure <label> text matches the accessible name. If using aria-labelledby, ensure referenced text matches visible label.
Note: These are official W3C resources for 2.5.3. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 2.5.3 Label in Name correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Operable PrincipleGuideline
2.5 Input Modalities