Keep the spoken control label in its accessible name

Identify the two representations

W3C’s SC 2.5.3 requires the accessible name to contain the visible text label. Placing that text first is best practice, not the entire requirement.

Choose a control with ordinary visible words and identify the exact component being reviewed. Keep nearby headings, explanatory text and status messages distinct from its label. The review should not grow into a general rewrite of all surrounding content. State the user’s intended action so a technically neat change does not rename the control into something misleading.

Obtain the receiving implementation’s name evidence from the qualified owner. A design-file annotation or a developer’s intended string is not necessarily the delivered value. Preserve where the evidence came from and whether it is actual computed output or only a supplied expectation. That distinction determines what the current review can establish.

Compare a specific mismatch

Fictional visible text is “Preview brochure”. Supplied name “Open document” omits it; “Preview brochure, new window” contains it. These string checks do not compute a browser accessibility tree or establish speech-engine behavior.

Keep each candidate beside the unchanged visible wording and describe the mismatch in plain language. Do not approve a hidden replacement merely because it sounds more polished or describes a related action. Ask the owner why the additional wording exists and whether it supplies useful context without confusing the task.

The local fixture checks only the supplied strings using a deliberately simple containment assertion. It is not a general conformance algorithm: real labels can involve language, punctuation and other interpretation questions requiring qualified review. No browser accessibility-tree inspection or speech-input execution is represented by this fixture.

Resolve the implementation discrepancy

Ask the implementer to trace which source supplies the delivered value before choosing a repair. An old component setting, an independently maintained translation or a recent visual rename could explain the discrepancy. These are hypotheses until the implementation evidence establishes the cause. Avoid fixing one screenshot while leaving another state or locale dependent on the same stale input.

Coordinate the wording change with the content owner. The goal is not to add every nearby instruction into one long string. Keep the control’s purpose understandable and have the accessibility reviewer assess how the implementation exposes any necessary supporting information. Do not remove useful context without checking the task that context serves.

For a stateful control, identify the specific state covered by the evidence and request the corresponding check after the state changes. A default view can be correct while a later action uses old wording. Keep the review scoped to supported states rather than promising that one corrected value approves every component variant.

Close with evidence at the receiving boundary

Prepare a discrepancy record containing the visible wording, supplied or observed value, source of that evidence and proposed correction. State clearly which layer has been checked. A string comparison may reveal an obvious disagreement, but it does not replace the receiving implementation review.

Request a demonstration using the approved synthetic task in the intended environment. The owner should record the actual conditions and outcome without exposing personal data or activating a consequential real action. If behavior remains inconsistent, preserve the observations and route the issue to the relevant specialist instead of asserting that the user pronounced the command incorrectly.

After a correction, repeat the relevant states and retain the version evidence with the component. When visible wording changes later, include this relationship in the change review rather than assuming hidden content updates automatically. The deliverable is a specific, traceable agreement between the representations and a candid account of remaining tests, not a universal claim about assistive technology.

Make the reasoning concrete.

A fictional publisher replaces a button caption during a design refresh. Its implementation handoff still contains an older supplied name. The reviewer can compare those strings but has not inspected the delivered component.

The publisher records the mismatch and the missing receiving evidence. No real interface or account is modified.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Control

   Which exact component and state are being reviewed?

2. Wording

   What visible text identifies its action?

3. Evidence

   Is the supplied value intended or actually observed?

4. Cause

   Which implementation source explains the discrepancy?

5. Receiving check

   What environment and safe task remain to be tested?

Watch for the wrong conclusion.

• Treating a design annotation as computed output.
• Fixing only the default state.
• Claiming speech compatibility from a string comparison.

Sources & scope

Original explicitly fictional fixtures and editorial workflows. Criterion explanations and their applications remain source-derived. Understanding pages are informative guidance; scoped checks do not prove full conformance or legal compliance. Local modeled checks are distinguished from receiving-browser and assistive-technology evidence.

• W3C: Understanding SC 2.5.3, Label in Name →Primary W3C guidance · Supports: Supports visible-label inclusion.