Voice Control Accessibility Tickets

Voice control findings become fixable when the ticket compares the visible label with the accessible name and names the spoken command that fails.

Use this guide for WCAG 2.5.3 Label in Name, speech input testing, icon buttons beside text buttons, translated labels, checkout CTAs, account menus, and custom controls whose accessible name does not match what users see.

Open this voice control finding in the generator

What to capture from the finding

Visible label: the exact button, link, menu item, tab, or field text users see on screen.
Accessible name: the name exposed by the accessibility tree, browser inspector, or assistive technology.
Spoken command: the phrase the tester tried, such as "click Place order" or "tap Shipping address".
Component state: default, hover, focus, disabled, expanded, selected, responsive, translated, or loading state.
User impact: whether the mismatch blocks checkout, hides account actions, slows navigation, or causes users to activate the wrong control.

Ticket structure

Title:
[Severity] Page or component: visible label does not match the accessible name

User impact:
Explain which speech input task fails and whether users can still complete the flow another way.

Evidence:
- Page or flow:
- Visible label:
- Accessible name:
- Spoken command tested:
- Component state or viewport:
- Actual result:
- Expected result:

Likely WCAG references to verify:
- 2.5.3 Label in Name, when the visible label is not included in the accessible name.
- 4.1.2 Name, Role, Value, when the control is missing a programmatic name or exposes the wrong role or state.

Acceptance criteria:
- The accessible name contains the visible label in the same language.
- Speech input users can activate the control by saying the visible label.
- Icon-only controls keep clear names that distinguish their purpose.
- The fix is verified in default, responsive, translated, and stateful versions of the component.

Paste your voice control note into the generator when you want this structure drafted from raw test evidence.

Example conversion: checkout CTA

Raw note:
Visible button says "Place order", but the accessibility tree exposes "Submit". Voice Control does not activate the button when the tester says "click Place order".

Developer ticket:
[Critical] Checkout review: Place order button exposes the wrong accessible name

User impact:
Speech input users may be unable to complete checkout because the command that matches the visible button text does not activate the control.

Evidence:
- Page: checkout review step
- Visible label: Place order
- Accessible name: Submit
- Spoken command tested: click Place order
- Actual result: voice command does not activate the primary CTA
- Expected result: the accessible name contains "Place order"

Likely WCAG references to verify:
- 2.5.3 Label in Name
- 4.1.2 Name, Role, Value

Acceptance criteria:
- The button's accessible name contains the visible text "Place order".
- The control remains a native button or exposes the correct button role.
- Voice control can activate the button by the visible label.
- Loading or disabled states do not replace the accessible name with generic text such as Submit, Continue, or Button.

Example conversion: icon and text controls collide

Raw note:
Product cards show an icon-only heart button beside a text link labelled "Save". Both controls expose the accessible name "Save", but one opens a saved-items page and the other saves the current product.

Developer ticket:
[Medium] Product cards: repeated Save names make voice commands ambiguous

User impact:
Speech input and screen reader users cannot reliably choose between saving the current product and opening the saved-items page.

Evidence:
- Component: product card
- Visible labels: heart icon button, Save link
- Accessible names: both expose Save
- Actual result: the command "click Save" has multiple targets with different actions
- Expected result: each control has a name that matches or clarifies its visible purpose

Acceptance criteria:
- The product action exposes a specific name such as "Save product".
- The saved-items navigation exposes a distinct name such as "Saved items".
- Visible text remains included in the accessible name where visible text exists.
- Repeated controls in a product grid include enough context when needed, without creating noisy names for every card.

Common fix directions

Prefer visible text as the name source: let the button or link text provide the accessible name unless there is a concrete reason to add context.
Do not overwrite text labels with generic aria-label values: "Submit", "Button", "Open", and "Click here" often make the control harder to operate by speech.
Keep translations aligned: translated visible labels and accessible names should be updated together.
Separate icon-only controls: give icon buttons specific names that describe the action, especially beside text links or repeated cards.
Retest state changes: expanded, selected, loading, disabled, and responsive states can accidentally replace a good name with a bad one.

Paste-ready input for the generator

Voice control or label-in-name finding:
Page or flow:
Control type:
Visible label:
Accessible name:
Spoken command tested:
Component state or viewport:
Actual result:
Expected result:
Related selector or component:
Retest notes:

Open the accessibility ticket generator and paste this structure with the audit note.