Voice Control Compatibility: Supporting Voice Control and Dragon NaturallySpeaking

1. Who uses voice control on the web and why

Voice control in the browser is used by a considerably larger and more diverse group of people than many developers assume. People with permanent motor impairments, for example after a spinal cord injury or with ALS, often use voice control as their primary input method for the entire computer, not just for text entry. Beyond that, there is a large group of temporary users, for example people with repetitive strain injury (RSI), a broken arm, or legal and medical professionals who use dictation software like Dragon NaturallySpeaking in their daily work for time reasons and occasionally use the same software for web navigation.

The key technical difference from screen readers: voice control software primarily reads the visible text on screen, not primarily the accessibility tree. Voice Control on macOS does show overlay numbers for every clickable element when 'show numbers' is enabled, but the preferred and faster command remains 'click [visible text]'. When that visible text is missing, the user is left with the cumbersome path via number overlays, which considerably slows down operation and makes it more error prone.

2. How Voice Control, Dragon, and Windows Speech Recognition technically navigate

All three major voice control systems work on a similar basic principle: they scan the visible page for interactive elements, extract their visible text content or accessible name, and build a command list from that, typically in the form 'click [text]'. Dragon NaturallySpeaking goes a step further and offers a 'MouseGrid' mode as a fallback for elements without recognizable text, but this mode is considerably slower than the direct command with the visible label.

It is important to understand that these systems consistently prefer visible text over the aria-label. If a button has both visible text and a differing aria-label, this can lead to a confusing situation known as WCAG success criterion 2.5.3 'Label in Name': a screen reader reads the aria-label aloud, while the voice control user tries to say exactly the visible text as a command. If the two do not match, the intuitive voice command simply does not work.

3. Why icon-only buttons without visible text fail

A cart icon, a magnifying glass icon for search, or a heart icon for the wishlist are visually self-explanatory for sighted mouse users, but offer no visible text at all that a voice control system could extract as a command word. Even a technically correct aria-label="Cart" only partially solves the problem: it makes the button accessible to screen readers, but Voice Control and Dragon give the user no hint that 'click cart' would be the right command, because nowhere on screen is the word 'cart' visible.

Users are then left either guessing what the element might be named, or falling back to the cumbersome number overlay mode. Both cost time and patience and turn a simple purchase intent into a frustrating trial and error exercise. This is exactly where the key difference from pure screen reader compatibility lies: an aria-label alone makes an interface technically accessible, but not voice control friendly.

<!-- Problematic: aria-label present, but no visible text.
     Voice Control users nowhere see the word "Cart". -->
<button type="button" aria-label="Cart">
  <svg class="h-5 w-5"><!-- cart icon --></svg>
</button>

<!-- Better: visible text present, only reinforced via sr-only
     when space is tight, never replaced -->
<button type="button">
  <svg class="h-5 w-5" aria-hidden="true"><!-- cart icon --></svg>
  <span>Cart</span>
</button>

4. WCAG 2.5.3 Label in Name: the concrete rule behind it

WCAG 2.5.3 requires, at level A, that the accessible name of an element, meaning the name available to screen readers and voice control software, contains the visible text. Concretely this means: a button with the visible text 'Next' must not carry an aria-label="Proceed to the next step", because the accessible name would then no longer contain the visible text 'Next', and a voice control user saying 'click Next' would come up empty.

What is allowed, however, is extending the visible text with additional context, as long as the visible text remains present as a substring, for example aria-label="Next: step 2, shipping" for a button with visible text 'Next'. The accessible name still starts with or contains exactly the word visible on screen, so both the voice command and the additional screen reader information work.

<!-- WCAG 2.5.3 violated: visible text "Next" is not a substring
     of the accessible name "Proceed to the next step" -->
<button aria-label="Proceed to the next step">Next</button>

<!-- WCAG 2.5.3 satisfied: visible text remains a substring of the name -->
<button aria-label="Next: step 2, shipping">Next</button>

5. Typical violations in Magento and Hyvä frontends

In many Hyvä themes, Label in Name violations show up in predictable places: mini cart icon, search icon, wishlist heart, quantity plus/minus buttons, and pagination arrows are frequently given only an aria-label, without accompanying visible text, because the visual design is meant to stay compact. Next and back buttons in the checkout wizard also sometimes use a generic aria-label like 'Proceed to next checkout step', even though the visible button text simply reads 'Next'.

The fix rarely requires a design change. In most cases it is enough to add a short visible text label next to the icon, responsively hidden if needed, or to phrase the aria-label so it contains the visible text as a prefix or in full instead of replacing it.

<!-- Checkout wizard: visible text stays part of the accessible name -->
<button type="button" aria-label="Next: payment method">
  Next
</button>

<!-- Quantity selector: plus button with visible symbol AND text -->
<button type="button" aria-label="Increase quantity by 1">
  <span aria-hidden="true">+</span>
</button>

6. Hiding visible labels responsively without removing them from the DOM

A common misunderstanding: developers often use display: none when space is tight on mobile devices to hide text labels and show only the icon. This, however, removes the text entirely from the accessibility tree, causing the accessible name to be lost and the situation to become effectively an icon-only button again, even though text still exists in the markup.

The correct solution uses visual hiding rather than complete removal, for example via an sr-only class that hides the text only for sighted users while keeping it in the accessibility tree and therefore available to voice control and screen readers. It is important to understand: voice control reads visible text, not the accessibility tree directly, so sr-only primarily helps screen readers. For genuine voice control compatibility on mobile breakpoints, text should stay visible where possible, for example shrunk rather than fully hidden, or at least supplemented via a tooltip pattern with a title attribute.

/* Text stays in the accessibility tree but is visually hidden --
   helps screen readers, but NOT Voice Control users, who scan
   the visible screen content */
.sr-only {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

7. Form fields: visible labels instead of placeholder text alone

The same underlying problem affects form fields that only carry placeholder text instead of a real label element. A voice control user saying 'click email address' to jump into a field finds no match if the placeholder reads 'your.email@example.com' instead of a real label 'Email address'. Placeholder text also disappears on focus, which is a well known UX problem in its own right, independent of voice control.

A visible label element, correctly linked to the input field via a for attribute or by nesting, solves both problems at once: it stays permanently visible and offers voice control software a clear, stable command text that does not disappear once the user starts typing or dictating.

8. Testing compatibility with voice control

On macOS, Voice Control can be enabled under System Settings, Accessibility, and tested directly against your own page without installing any additional software. The simplest test flow: perform every important interaction on the page, open the cart, start a search, add a product to the wishlist, exclusively via voice command using the visible text, without falling back to the number overlay mode.

For Windows environments, the built-in Windows Speech Recognition offers a free testing option, while Dragon NaturallySpeaking as commercial software is mostly common in professional contexts like law or medical offices, so a full test with it is usually only feasible on a spot-check basis. Automated tools like axe-core reliably check WCAG 2.5.3 as a dedicated rule and should be built into every CI pipeline as a first line of defense before a manual voice control test happens.

9. Practical checklist for voice control compatibility

Five points can be checked in every code review: first, does every interactive element carry visible text or an accessible name that contains the visible text as a substring. Second, are icon-only buttons supplemented with visible text where possible instead of relying solely on an aria-label. Third, is display: none never used to hide text for space reasons that is actually meant to remain part of the accessible name.

Fourth, do form fields use real label elements instead of relying solely on placeholder text. Fifth, is an automated axe-core check run against the 'label-content-name-mismatch' rule for every new interactive component, which covers exactly WCAG 2.5.3 and surfaces violations before a manual test even happens.

10. Summary

11. FAQ: Voice Control Compatibility: The Essentials at a Glance