Label doesn't make sense in context

What is this issue?

A button or link’s accessible name consists entirely of a short, generic verb or acknowledgment with no object, such as “Close,” “Submit,” “Go,” “Next,” or “OK,” and nothing else in the accessible name supplies the missing context. This differs from an empty name (which announces nothing at all) and from a repeated-but-individually-fine label (which is only ambiguous once duplicated); here, the single word itself never carries enough information, no matter how many times it appears.

The word is usually visually correct and sufficient for a sighted user who sees the button inside its specific modal, form, or card and infers the missing context spatially. Nothing in the accessible name replicates that spatial inference for someone who can’t see the layout.

Why does this matter?

Screen reader users routinely navigate by pulling up a list of every button on a page, the same way they pull up a links list, specifically to jump straight to a control without reading everything around it. A button that just says “Close,” heard with no surrounding context, gives no clue what it closes: is it the whole page, a modal, a banner, a tooltip? On a page with more than one dismissible element, “Close” heard in isolation is functionally as uninformative as no name at all.

This is a subtler failure than a missing name, which is why it’s easy to miss in casual review: the button clearly has a name, and that name is a real, correctly-spelled English word. The gap only becomes obvious the moment someone tries to act on the name alone, without the surrounding visual layout that made it seem sufficient during development.

Who is affected?

• Screen reader users hear a short, correctly-formed word that carries no information about what it acts on, especially disruptive in a buttons list where several such generic labels can appear together.
• Cognitive disabilities: users relying on clear, self-explanatory action labels to navigate confidently lose that support when the label requires inferring context from a visual layout they may be skimming past rather than reading in full.

What users experience

Diego uses NVDA on his Windows laptop to review a support page that has a live-chat widget, a cookie-consent banner, and a newsletter signup modal all open in different corners of the screen at once. He tabs through the page and hears “Close, button” three separate times with no distinguishing information between any of them. Rather than risk dismissing the wrong one, especially the chat widget he actually wants to keep open, he stops tabbing and asks a colleague to describe what’s currently visible on his screen before he acts.

How do I fix it?

Add an aria-label that names the specific thing the control acts on, keeping the visible text as short as the design requires. This works because aria-label overrides the announced accessible name entirely without touching the rendered text, so a compact “Close” button stays visually compact while its accessible name becomes “Close cookie banner” or “Close login modal.”

Write the label from the control’s actual context, not a generic template: a modal’s close button should name that specific modal, not just say “Close dialog” for every dialog on the site. If several similar controls exist on one page (three “Close” buttons across three panels), make sure every one gets its own distinct, specific label rather than fixing only the first one you notice.

Code Examples

<div class="modal" id="login-modal">
  <button>Close</button>
  <!-- login form -->
</div>

<div class="modal" id="login-modal">
  <button aria-label="Close login modal">Close</button>
  <!-- login form -->
</div>

The visible button still shows the short word “Close,” matching the compact design a modal’s corner button usually needs, while its accessible name now specifies exactly what it closes: the piece of information a sighted user gets for free from the button’s position inside the modal.

Common Mistakes

Mistake: “The button is inside the modal, so its context is obvious.” That spatial relationship is obvious to a sighted user reading the page visually, but a screen reader user pulling up a flat buttons list encounters the label completely detached from its surrounding markup: the DOM nesting that makes context “obvious” to a sighted reader provides no such cue in a linear announcement.

Mistake: “Every ‘Close’ button on the site should just get the same generic aria-label, like ‘Close panel.’” A shared generic label across every instance solves nothing; it replaces one ambiguous word with a slightly longer, still-ambiguous phrase, since “Close panel” still doesn’t say which panel when three exist on the same page. Each instance needs its own specific text.

Mistake: “Making the button text itself longer and more specific is always better than using aria-label.” Sometimes that’s true, but a design that deliberately keeps buttons short and consistent, such as a row of icon-free “Close,” “Save,” “Cancel” buttons across a design system, has a real reason to keep the visible text compact. aria-label lets you meet both goals instead of forcing a tradeoff between design consistency and accessibility.

How RedFlag Detects This

AI-assisted: flagged by the optional Review Labels feature. RedFlag’s label-review workflow flags interactive elements whose accessible name matches a small set of short, context-free action words with no further descriptive text, and a human reviewer confirms whether the specific instance genuinely lacks sufficient context before it’s recorded as a violation. This is a hybrid flag-then-confirm process, not a deterministic DOM rule that runs unattended on every scan.

False negative: a generic-sounding but genuinely sufficient label, such as “Play” on a single, unambiguous audio player with nothing else competing for that word on the page, can be under-flagged if a reviewer reasonably judges the context to already be clear. False positive: a short label that’s actually fine because it’s the only interactive element of its kind on the entire page (a single “Submit” button on a one-field form) can still surface for review even though no ambiguity exists in practice. Manual step: the reviewer’s judgment call, whether the word alone, heard with zero surrounding context, communicates enough, is the actual detection mechanism, not an automated string match alone.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or JAWS running.
2. Pull up the buttons list (NVDA/JAWS: Insert+F7, then filter to Buttons).
3. Read through every short, generic-sounding entry, such as “Close,” “Submit,” “OK,” or “Go,” with no other page context in mind.
4. For each one, ask whether you could tell what it acts on from the word alone. If the page has more than one control sharing the same generic word, that’s an automatic fail for every instance beyond the first.

Related WCAG Success Criteria

2.4.6 Headings and Labels: Headings and labels must describe topic or purpose. A single generic action word with no object fails this requirement outright, independent of whether it’s duplicated elsewhere on the page; it never described its purpose to begin with.

Related Issues

Label is ambiguous without surrounding context is the closely related sibling check under the same criterion: labels that work fine individually but become indistinguishable once repeated, rather than single labels that never carried enough information in the first place.

Link text is generic and gives no context covers the equivalent pattern for links specifically, matched against a fixed list of exact generic phrases rather than reviewed by a human.

Heading text is vague or generic applies the same “describes purpose” question from 2.4.6 to headings instead of interactive controls.

Alt text is a raw filename is a related naming failure reviewed through the same AI-assisted label-review workflow, on images rather than buttons or links.

Button or link has no accessible name is the more severe neighboring failure: no name at all rather than a name that exists but carries no context, and the one automated check RedFlag runs on every scan for the closest-related problem.

References

• W3C Understanding 2.4.6: Headings and Labels
• W3C Technique G131: Providing descriptive labels
• MDN: aria-label