We all navigate the internet and computers in different ways. Some use screen readers, others keyboard, and some people by voice. Success Criterion 2.5.3 was created to support these diverse methods. While it helps all users, it was created to address using voice control because typing is a struggle for the user. On the screen is a button that clearly says “Submit Order.” You speak the command: “Click Submit Order.”
Nothing happens.Or worse, it clicks the wrong thing.
This isn’t a bug in your brain. It’s a disconnect in the code. This is exactly what we’re trying to fix. And honestly, it’s one of those criteria that feels obvious once you understand it, but is surprisingly easy to miss when you’re deep in the weeds of development.
The Core Concept: Alignment
The rule is simple, but the impact is profound:
If a user interface component has a visible text label, that exact text (or a string that contains it) must be present in the component’s accessible name.
The text a sighted user sees on the screen must match the text a screen reader or voice control software finds in the code.
Why does this matter?
Because for users of speech recognition software (like Dragon NaturallySpeaking or built-in OS voice control), the visible label is their map. They navigate by saying what they see. If the code says aria-label="Go to Checkout" but the screen says Pay Now, the user is lost. They are trying to navigate a world that doesn’t match their reality.
Including the visible label in the accessible name respects the user’s intent to interact with the thing they are looking at. When the visible label and the accessible name diverge, you are essentially telling the user: “What you see is not what you get.” That is a fundamental breach of trust in the interface.
Common Pitfalls (And How to Fix Them)
I’ve seen this fail in a few classic ways during audits:
- The Icon-Only Button with a Tooltip:
- Visual: A trash can icon.
- Tooltip: “Delete Item.”
- Code:
aria-label="Remove" - The Fail: A voice user never sees “Delete Item” tooltip. The user says, “Click Delete”. The command fails.
- The Fix: Make the
aria-labelmatch the tooltip or the visible text if it were there.aria-label="Delete Item".
- The Icon-Only Button:
- Visual: A trash can icon.
- Code:
aria-label="Remove" - The Fail: A voice user sees “Delete Item” and tries to say “Delete.” The command fails.
- The Fix: Make the
aria-labelmatch the most common interpretation of the icon. Not all icons are part of a users social lexicon. Most people will see an envelope graphic and think ma or messages. Someone with a learning disability, detachment from social concepts, autism, or simply from another part of the world may not connect the envelope with email.
- The “Hidden” Text:
- Visual: A button that says “Search”.
- Code:
aria-label="Find everything on this site" - The Fail: While “Find everything…” is descriptive, but it’s long and doesn’t contain the word “Search.” A voice user might try “Click Search” and fail.
- The Fix: The button has text. Don’t add anything. If you have to, keep it tight and use the K.I.S.S. approach.
aria-label="Search"
- The Decorative Image Trap:
- You made a control that only uses an icon. You failed. Look at method number 2.
The People-First Warning
It is tempting to treat 2.5.3 as a “compliance checkbox.” “Okay, I added the aria-label, I passed the validator, I’m good.”
But that misses the point. This isn’t about passing a test. It’s about predictability.
When we allow the visible label and the accessible name to drift apart, we are creating a fragmented reality for our users. We are forcing them to memorize a second layer of language that doesn’t match the visual world. For someone with cognitive disabilities, or for someone relying on voice control who is already fighting against the limitations of their environment, this extra cognitive load isn’t just annoying but is a major barrier to entry.
Ask yourself: If I were navigating this site with my eyes closed, would the words I hear match the words I see? If the answer is “no,” you aren’t just failing a criterion; you’re failing the person on the other side of the screen.
The Bottom Line
2.5.3 is a reminder that accessibility isn’t just about adding features that check a box. It’s about ensuring that the digital world speaks the same language to everyone, regardless of how they access it.
So, next time you’re coding a button, a link, or a form field, take a second look. Does the code say what the screen says? If not, fix it. Your users are counting on you to make sure the map matches the territory.
Have questions, thoughts, or discussion? Find on LinkedIn and BlueSky!
Comments are closed.