Reviewed November 3, 2026

Label in Name: When Your Button Says One Thing and Announces Another

Success criterion 2.5.3, Label in Name, Level A, says that where a component has a visible text label, its accessible name must contain that text, ideally at the start. Voice control software works by matching speech to accessible names, so a shopper who says click Add to Bag needs the button's name to begin with those words. Storefronts break this constantly with aria-labels written by a different team than the one that wrote the button: the label says Buy Now, the name says Purchase this product SKU 4417, and the voice command lands nowhere.

This failure is invisible to sighted testers and silent in most automated scans, which check that a name exists, not that it matches the words on screen. It is found by the user group least able to work around it: people who drive the browser entirely by voice, for whom a mismatched name is not an inconvenience but a locked door on that control.

The divergence creeps in innocently. A developer improves an icon button's aria-label for screen readers, a copywriter shortens the visible label for mobile, a translation updates one string and not the other. Each edit is reasonable. The pair drifts apart, and 2.5.3 exists precisely because that drift is the default outcome without a rule.

Where stores break it most often

Icon plus text buttons are the first site: a heart icon with the word Save beside it, named Wishlist in the code. Search is the second: a field labeled Search on screen whose accessible name is a paragraph of instructions. Checkout breeds the exotic cases, express payment buttons and quantity steppers whose names were written for a different design three templates ago.

Social and sharing links deserve a pass too. Visible labels get trimmed to platform names on mobile while the names keep marketing copy. Whatever the user sees is what they will say, and what they say is the only key voice software has. The rule is generous, the name may contain more than the label, but it must start with the visible words.

Fixing it without breaking screen reader experience

Start from the visible text. Build the accessible name as label first, context after: Add to Bag, denim jacket, size medium, is a conforming name that serves a screen reader user better than the bare label anyway. Where the visible text is complete by itself, the strongest move is deleting the aria-label entirely and letting the text content be the name, removing the second string that can drift.

Put the pair under one owner. The template file that renders the label should compute the name from the same variable. In code review, treat any hard coded aria-label on a labeled control as a smell that needs a reason. And test with an actual voice tool once per template; five minutes of speaking your own checkout exposes mismatches no checklist reading will.

The business translation, for teams that need one

Voice control users are shoppers with money and a checkout in front of them. A store that fails 2.5.3 is not failing an abstract standard; it is declining completed purchases from a group with high intent and few workarounds. The fix costs minutes per template because it is a naming discipline, not a redesign.

It is also Level A, the floor of the standard, present since WCAG 2.1. In an audit report, an A failure on money pages reads badly to everyone, including the plaintiff side experts who catalogue exactly these findings. There is no strategic reason for this criterion to be on any store's open list.

Frequently asked questions

What is the difference between a label and an accessible name?

The label is what sighted users see on or beside the control. The accessible name is what assistive technology announces and what voice software matches against. They are two strings describing one control, and 2.5.3 governs the relationship between them.

Can the accessible name be longer than the visible label?

Yes. Extra context after the label is allowed and often helpful, as long as the name starts with the visible label text. Voice users speak the beginning; matching from the start is what makes commands reliable.

Does an icon only button have a label in name problem?

A control with no visible text label is outside the core of 2.5.3, since there are no visible words to match. It still needs a sensible accessible name under other criteria. The moment text sits beside the icon, the pairing rule applies.

Which tools catch label in name failures?

Most automated tools check for the presence of a name, not its agreement with the visible label, so this criterion is mainly a manual and voice testing catch. Browser accessibility inspectors show the computed name beside the element, which makes a template by template spot check fast.