A website is usually tested in three ways: with the mouse, with the keyboard and with a screen reader. A fourth way of operating it slips through that net on a regular basis. People who drive their computer by voice say the words that stand on the screen — “Click Add to cart”. Whether that command lands is decided not by the visible text but by the accessible name of the control. If the two diverge, the command goes nowhere, even though the same button is reachable by keyboard and announced cleanly by a screen reader. Success criterion 2.5.3 Label in Name in WCAG 2.2 (W3C) closes exactly this gap, and it does so at Level A. This article shows how speech input works technically, where the accessible name typically diverges and how to test the whole path with the browser tools you already have.
Key takeaways
- Speech input uses the visible text as the command. If the accessible name does not cover that text, the element cannot be addressed by voice — even when keyboard operation and screen reader output are in order.
- Success criterion 2.5.3 Label in Name (W3C) sits at Level A, the lowest conformance level of WCAG 2.2. It therefore belongs in the mandatory part of every WCAG audit.
- The harmonised standard adopts the criterion verbatim in clause 9.2.5.3 (EN 301 549). Through the BFSG requirements it becomes a duty for economic operators.
- The most frequent causes are an aria-label that replaces the visible text instead of containing it, icon buttons without a text reference and labels that exist only as graphics.
- The path can be tested without special software: compare visible text and accessible name in the browser accessibility tree and note every difference.
A fourth way of operating that is rarely tested
The starting position is known: 95.9 percent (WebAIM Million) of the home pages surveyed in February 2026 carried machine-detectable WCAG failures, an average of 56.1 (WebAIM Million) errors per page. The survey evaluates the home pages of the one million most visited websites automatically and therefore captures only part of the barriers that exist — anything requiring human judgement does not show up there at all. For speech input it is instructive nonetheless, because the most frequent findings concern exactly the elements a voice command latches onto: buttons without text, form fields without labels and links without a usable name. Fixing those three groups improves more than the score of a testing tool; it makes the page addressable in the first place.
How many people need this path can only be approximated. At the end of 2025 a good 7.8 million (Statistisches Bundesamt) people with a severe disability lived in Germany; for 10 percent (Statistisches Bundesamt) of them the function of arms or legs was restricted. Worldwide the World Health Organization estimates 1.3 billion (WHO) people experiencing significant disability, which is 16 percent (WHO) of the world population. Speech input is not tied to a diagnosis: it helps after a hand injury, with tendinitis, with tremor and in situations where both hands are needed elsewhere. The audience for this path is therefore considerably larger than the disability figures alone suggest.
Two questions missing from the test report
How a voice command reaches the browser
Speech input software does not work on the pixels of the screen but on the accessibility tree the browser builds from the document. Every control gets an accessible name, a role and a state there. When somebody says “Click Submit”, the software searches the tree for an element with the button role whose name contains the word “Submit”. If it finds exactly one, it activates it. If it finds several, it numbers the hits and waits for a choice. If it finds none, nothing happens — and without an error message, because from the point of view of the software no matching element exists. To the person operating the page it looks like a broken button.
The accessible name is assembled in a fixed order of precedence. An aria-labelledby points to other text in the document and beats everything else. Then comes an aria-label, then an associated label element, then the text content of the element itself, then an alt attribute, and last a title. Each of these steps can push the visible text out. That is where the break sits: adding an aria-label with the value “Buy now” to a button that reads “Add to cart” removes the visible text from the name. The screen reader announces “Buy now”, the speech input no longer knows “Add to cart”. Both outputs come from the same line of source, and only one of them shows up in a customary test.
| Question | Keyboard | Screen reader | Speech input |
|---|---|---|---|
| What the path acts on | focus order in the document | accessibility tree, read aloud | accessibility tree, searched |
| What the operating person perceives | the visible focus ring | the announced name | the visible text |
| When it breaks | element is not focusable | name is missing or empty | name does not cover the visible text |
| Success criterion | 2.1.1 Keyboard, Level A | 4.1.2 Name, Role, Value, Level A | 2.5.3 Label in Name, Level A |
| Typical finding | custom div instead of button | icon without a text alternative | aria-label replaces the text |
The table shows why a clean screen reader test does not cover speech input as well. Both paths read the same tree but draw opposite conclusions: for spoken output a precise name that diverges from the screen is often an improvement, for speech input it is a barrier. A screen reader test answers the question “Is the element announced understandably?”. Speech input asks the other one: “Can I call the element by the name I can see?”. Asking only the first question leaves the second class of findings undetected in our experience.
2.5.3 Label in Name: the rule in one sentence
The success criterion is short. In WCAG 2.2, published in its current form as a recommendation on 12 December 2024 (W3C), it says in substance: for user interface components with labels that include text or images of text, the name contains the text that is presented visually. Three formulations carry the whole rule. “Contains” means the name may say more than the label, but it has to carry the visible text in full. “Presented visually” means what counts is what stands on the screen, not what stood in the design file. And “user interface components” narrows the scope — the criterion does not apply to headings and body copy.
Two details decide the finding in practice. First, only text in the immediate vicinity of the element counts as a label: to the left of input fields and select lists, to the right of checkboxes and radio buttons, inside buttons and tabs. A heading two sections further up is not a label in the sense of the criterion, even when it fits the content. Second, the standard recommends placing the label text at the start of the name. That is not mandatory, but it makes operation considerably easier, because many speech input tools sort multiple hits by order and a leading addition lengthens the hit list without need.
aria-label overrides
An aria-label replaces the visible text completely. Useful for icon buttons without text, harmful as soon as a visible label exists.
Label as a graphic
If the text sits in an image file, the alternative text has to carry it word for word. A descriptive “company logo” instead of the depicted word breaks the voice command.
Icon without a text anchor
A magnifier icon often carries the name “Search” while no word is visible. 2.5.3 does not apply here, but the expectation of the operating person does.
Addition before the label
Names such as “Read more: accessibility in retail” start with the addition. Permitted as long as the visible text is contained, but harder to hit.
Special characters and ligatures
Typographic quotation marks, non-breaking spaces and ligatures in the name create differences that stay invisible in a screenshot.
Placeholder instead of a label
If only a placeholder sits in the field, it becomes the sole visible label — and then it has to appear in the name as well.
These six patterns cover most of the findings we encounter in audits. They share one trait: all of them arise from an attempt to improve output for screen readers. A team that uses aria-label generously means well and creates the hidden command along the way. That is why comparing screen and tree belongs in the same review round as ARIA roles and states — otherwise one round removes what the other has just built up.
A divergent name is a hidden command
Where the accessible name typically diverges
The order of magnitude can be read from the survey. 30.6 percent (WebAIM Million) of home pages carried empty buttons, 46.3 percent (WebAIM Million) empty links. In forms, at least one field label was missing on 51 percent (WebAIM Million) of pages; across all form inputs found, 33.1 percent (WebAIM Million) were not properly labelled. An empty element has no name at all and cannot be addressed by voice — the extreme case of 2.5.3, formally a failure of 4.1.2 Name, Role, Value. WCAG states explicitly that a control lacking an accessible name while carrying a visible label fails both criteria.
The second block consists of elements that do have a name, but the wrong one. On 15.2 percent (WebAIM Million) of home pages the link text was ambiguous, such as “click here” or “more”. Such links frequently carry an aria-label with the actual destination — which serves the screen reader and locks out speech input, because the spoken visible text “more” no longer occurs in the name. How widespread this intervention is shows in the ARIA figures: home pages carried an average of 31.4 (WebAIM Million) attributes of type aria-label, aria-labelledby or aria-describedby and 4.8 (WebAIM Million) occurrences of role="button". Every one of these attributes is a place where the name can diverge from the screen.
- Every button with visible text carries that text in its accessible name — without rewording, without shortening.
- Icon buttons without visible text get a name matching what operating people would say: “Search”, “Menu”, “Close”.
- Links with generic text get the addition after the visible text, not before it and not in its place.
- Input fields have a visible label via a label element; a placeholder does not replace it.
- Labels inside graphics carry the depicted wording in the alternative text.
- Controls that change their text — expand and collapse — change their name along with it.
- Where several identically named elements sit on one page, it has been checked that speech input can tell them apart sensibly.
The second-to-last line is overlooked most often. A toggle whose label alternates between “Show more” and “Show less” has to reflect both states in its name as well. If the name stays constant, after the first click speech input operates an element that displays something other than what was called. The same applies to filters and sorting in an accessible product search whose labels change with the selection, and to tabs that show the active state by colour alone.
From standard to legal duty
WCAG is a W3C recommendation without direct legal force. It becomes binding through the harmonised European standard. EN 301 549 adopts the success criterion verbatim in clause 9.2.5.3 (EN 301 549) for web pages and again in clause 11.2.5.3 for software. In addition, the standard names speech input explicitly in its section on functional performance statements: clause 4.2.7 (EN 301 549) requires operation without fine motor actions for people with limited manipulation or strength and lists speech user interfaces as one way of getting there. Anyone reading the standard behind the BFSG therefore finds speech input not as a special case but as a planned way of operating.
The step into German law is taken by the Barrierefreiheitsstärkungsgesetz. Under section 3 paragraph 1 (BFSG), products and services are accessible when people with disabilities can find, access and use them in the customary manner, without particular difficulty and in principle without outside assistance. The concrete requirements sit in the accompanying regulation, which refers to the state of the art — and for websites that is EN 301 549. The underlying directive has been applied since 28 June 2025 (EU-Richtlinie 2019/882); since then it covers, among other things, electronic commerce, consumer banking services and e-books.
For companies with customers in several member states a look across the border pays off, because national implementations differ in detail; we have collected that in our overview of accessibility abroad. Inside the company the path has a second side: employing staff with limited hand mobility calls for internal tools that can be operated by voice — and a career page without barriers on which the application can be submitted in the first place.
Two roles, two duties
Test grid: speech input in half a day
A reliable picture emerges faster than most expect. You do not need speech input software to answer the core question — the comparison between visible text and accessible name can be read in the developer tools of every common browser. Pick the five pages your business runs on: home page, search or overview, detail page, form, completion. Then work through this order.
- Open the accessibility tree in the developer tools and keep it next to the rendered page.
- Tab through all controls and note the visible text and the displayed name for each element.
- Mark every line in which the visible text does not appear in full in the name. That is your finding list for 2.5.3.
- Check separately all elements without visible text: icon buttons, close crosses, arrows in image galleries.
- Search the source for aria-label and aria-labelledby and compare each hit against the text visible beside it.
- Open and close every expandable element and watch whether the name moves with it.
- Have the page operated once with real speech input — the built-in tools of common operating systems are enough for a first pass.
- Record for each finding whether it sits in your own source or in an embedded component.
The last point decides the effort. A finding in your own markup is usually one line. A finding in a purchased building block or an embedded external element needs a different route — and sometimes a decision against the block. How responsibility is distributed depends on the way it is embedded; the ground rules are in our article on responsibility for third-party elements.
| Finding | Solvable in your own project | Sits with the vendor |
|---|---|---|
| aria-label replaces the visible text | yes, remove or extend the attribute | when the attribute comes from a library |
| Button without any name | yes, add text or a label | with encapsulated components lacking an interface |
| Label exists only as a graphic | yes, align the alternative text | with automatically generated graphics |
| Name does not change with the state | yes, add state logic | with external controls |
| Payment step in an external frame | only through the choice of provider | yes, with evidence in the procurement record |
This classification changes the conversation with suppliers. Instead of a general question about accessibility, a concrete requirement is on the table: the accessible name of every control contains the visible text. That is testable, provable and can be written into an acceptance criterion. For procurement itself we have described the requirements in our article on public tenders.
From fixing once to testing continuously
A cleaned-up state holds until the next component is added. Because a divergent name has no visible symptom, the relapse is rarely noticed at acceptance: the page looks the same, keyboard operation works, the screen reader even reads out something sensible. That is why the rule belongs in development, not only in testing. An accessible design system can enforce it by binding the visible text of its button component to the name and rejecting a divergent aria-label.
The second building block is repetition. We recommend adding the comparison to the acceptance list of every larger change and additionally running it over the core pages at a fixed cadence — that is the heart of our BFSG monitoring. Teams that want to keep this in house will find the part that concerns development and editing alike in our training: what belongs in the name is often an editorial decision, implemented in the component.
A control whose name contains the visible text is reachable by mouse, keyboard, screen reader and voice alike. A name that diverges from it serves exactly one of those paths better and shuts out another.
Getting started is manageable. Comparing visible text and accessible name is a test step of its own with a clear result: a list of elements that cannot be reached by voice, sorted by business relevance. That list turns into a work sequence for accessible web development, and recurring patterns turn into a rule in the design system. Which services work together here is shown in the overview of our services.
Sources and Studies