Why a button can have two different names
A person can see a button labelled “Check availability” and say those words to speech-control software, yet nothing happens. The visible text is one thing; the accessible name exposed by the page is another. If code overrides the button with an aria-label of “Search slots,” the software may listen for the latter while the customer naturally speaks the former. W3C's Label in Name criterion says that for a user-interface component with a label containing text or an image of text, its accessible name contains the visually presented text. Putting the visible phrase at the start of the name is a best practice. This criterion is about controls that have a visible label; it does not itself require inventing visible text for every icon-only control, although other accessibility requirements still matter. The problem is easy to miss in a visual review because both versions look identical on screen. It can also appear after a content edit: marketing changes “Send enquiry” to “Request a quote,” while an invisible label stays at the old wording. Treat the visible phrase and computed name as one content decision that needs testing after every interface change.
Audit the controls a customer actually uses
Walk a complete customer path and list visible buttons, links, form labels, tabs and menu items. Prioritize actions that move money, submit information, change a booking, or select a product option. For each control, record the text a customer sees in the current language and the computed accessible name shown by browser accessibility tools. The latter is the result after naming rules are applied, not simply the raw aria-label attribute. A native button often gets its name from its own visible text. An associated form label can name an input. aria-label or aria-labelledby may override what a developer expects, so looking at source code alone is insufficient. Check dynamic states too: “Add to basket” might change to “Added,” while the old accessible name remains; a language switch might translate the visible text but leave an English hidden label. Duplicate controls need enough context to distinguish them, but added context should preserve the entire visible phrase. W3C technique G208 explains that the visible text can be followed by extra words in the accessible name; it also notes that extra context may belong in a description rather than the name. The audit should identify actual mismatches before a team starts rewriting labels across the site.
Work through a quote request
Consider a Hong Kong maintenance company's quote page. A customer chooses an appliance type, enters a district, and reaches a visible “Get estimate” button. The developer once set aria-label to “Submit form” to make the purpose clearer to a screen reader. The computed name is now “Submit form,” so a person who says “click Get estimate” may fail to activate the button. The direct repair is to let the button's visible text provide its name, provided that “Get estimate” truthfully describes the action. If extra context is needed because several estimates appear on the page, the name can begin with “Get estimate” and then add a distinguishing service phrase, or the context can be supplied through a suitable description. The exact approach should be tested with the page's interaction design. On submission, if the button changes to “Request sent,” update the computed name and state in a way that reflects what actually happened. Do not label it “Quote confirmed” if the business merely received an enquiry. This is an illustrative case, not a report of an actual client result. Its acceptance test is that the visible phrase can be used to find and activate the control in both language editions.
Preserve wording and order when adding context
W3C's criterion requires the accessible name to contain the text presented visually. Its understanding material explains that capitalization and most punctuation differences generally do not matter for the speech-control purpose, but replacing words with different words does. Technique G208 tests whether the accessible name contains the same letters in the same order as the visible label. A visible “Save changes” paired with a name of “Update profile” therefore needs attention even if a designer considers them synonyms. “Save changes to delivery address” is a better extended name because it starts with the words the customer can see. A visible “More” link may need context, especially when several appear. Add the associated item after “More,” or use a distinct visible phrase if the layout allows; avoid making the hidden name wholly different. An aria-describedby reference can carry explanatory text without changing the name computation, so a field can remain named “Delivery date” while its description says which dates are available. Avoid using a description to conceal an ambiguous action. If the visible label itself is misleading, fix the visible language before preserving it in code.
Treat English and Chinese as separate checks
A bilingual page can pass in English and fail after localization. Visible “Choose plan” might become “選擇方案,” while an untranslated aria-label still says “Select subscription.” The code may be functional for a screen reader yet the visible Chinese phrase will not be a usable speech target. Audit each language after rendering, because the final computed name may combine a translated button with an untranslated hidden span, nearby heading, or template string. Keep the same decision meaning across languages without forcing literal word order. If Chinese visible text is “更改地址,” the Chinese accessible name should include that phrase in the same order; it does not need to imitate the English sentence structure. If product names or model codes appear within a control, verify that the rendered label and name expose the same identifying text, then test pronunciation and recognition with users or suitable assistive technology when possible. Avoid claiming universal speech recognition from a code inspection; recognition depends on software and language settings. The team's evidence can be narrower and honest: the computed names include the visible phrases, and an agreed test setup activates the controls with those phrases.
Handle icons, images of text and changing states
Do not apply the rule mechanically to controls with no visible text. The Label in Name criterion concerns components with labels that include text or images of text; an icon-only control has a separate need for a meaningful accessible name under other criteria. If an icon is next to visible words, work out whether the words label the same control and ensure the computed name includes them. If a promotional graphic contains readable words that act as the control's label, those words count even though they are drawn into an image. Avoid using images of text when ordinary text would work, because ordinary text is easier to keep synchronized across languages and states. Dynamic controls need repeated inspection: a button may alternate between “Show details” and “Hide details,” and its name must follow the currently visible action. A disabled state does not justify changing its name to a hidden explanation; explain why it is unavailable through a separate suitable message or description. For a button that starts loading, test whether changing visible text, accessible name, and status together creates repeated announcements. Keep the action clear before, during, and after the transition without implying completion before the server confirms it.
Use a repeatable release check
Choose a representative page in each language and walk it from entry to confirmation. For every visible labelled control, capture its visible phrase, computed name, state, and intended action. Mark a mismatch if the name omits or reorders the visible words, or if a translation or state change leaves old text behind. Repair the source of the override rather than adding another hidden label on top. Then test by keyboard and screen reader to make sure the control still has the intended role and context. Where speech input is available, speak the visible phrase and confirm the expected control activates; repeat when several similar controls share a page. Document the browser, assistive software, language, and outcome so another editor can repeat the check. A passing automated rule is useful as a prompt, but a tool may not know which adjacent text is the actual visible label or whether a business action is truthfully named. Release only when the customer-facing wording, computed name, and actual action tell the same story. Recheck after design, translation, or component-library changes, because any of them can change name computation without visibly changing the button.
Before you proceed
- Does every visible labelled control expose that same phrase in its computed name?
- Do translated and changed states update the name as well as the visible text?
- Can the visible phrase activate the intended control in the agreed speech-input test?
- Does the label truthfully describe what the action does?
