Label is ambiguous without surrounding context

What is this issue?

A link or button’s accessible name (the text a screen reader announces to identify an element) repeats identically across multiple instances on the same page, where each instance is only disambiguated by nearby visual content like a heading, a table row, or a card title. “View issues,” “Manage settings,” or “Renew subscription” are all reasonable link text when read next to the specific item they belong to, but say nothing distinct once separated from that surrounding layout.

This differs from text that’s vague everywhere: the label genuinely does its job for a sighted user scanning the page in order. The failure is specifically that assistive technology navigation modes, which routinely strip elements out of their visual context, expose the ambiguity that visual layout was masking.

Why does this matter?

Screen readers offer navigation modes built specifically to skip past surrounding content, such as a links list, a buttons list, or a rotor of interactive elements, precisely so users can jump straight to the control they want without reading the whole page first. Repeated ambiguous labels defeat the entire purpose of those modes: instead of a scannable menu of distinct options, the user gets the same phrase repeated as many times as it appears on the page, with no way to tell which one does what.

This scales badly. A dashboard listing ten projects, each with its own “View issues” link, produces ten indistinguishable entries in a links list, functionally as broken as if none of them had any text at all, even though each one reads perfectly well in its visual row.

Who is affected?

• Screen reader users lose the ability to use a links or buttons list to scan and choose among repeated-label controls, since every entry announces identically regardless of which item it actually belongs to.
• Cognitive disabilities: users skimming a page by jumping between interactive elements, rather than reading full paragraphs, lose the same disambiguating context sighted skimming naturally provides through visual position and proximity.

What users experience

Priya uses JAWS on her Windows laptop to review a project management dashboard listing eight active projects, each in its own card with a “View issues” link. She presses Insert+F7 to pull up JAWS’s links list, expecting to jump straight to the project she needs. Instead she hears “View issues, link” repeated eight times with no way to tell them apart, so she closes the list and tabs through the entire dashboard card by card instead: the exact shortcut the links list exists to provide, unavailable because every entry says the same thing.

How do I fix it?

Add an aria-label to each repeated control that folds in the specific subject it relates to, while keeping the shorter visible text unchanged for sighted users. This works because aria-label completely overrides the announced accessible name without touching what’s rendered on screen, so the compact “View issues” design stays intact while each link becomes independently identifiable to assistive technology.

Derive the label text from the same data driving the visible content, such as the project name or the item title, rather than writing a separate hardcoded string, so the fix scales automatically as new items are added instead of needing a manual update every time.

Code Examples

<div class="project-card">
  <h3>Marketing site redesign</h3>
  <a href="/projects/12/issues">View issues</a>
</div>
<div class="project-card">
  <h3>Mobile app v2</h3>
  <a href="/projects/13/issues">View issues</a>
</div>

<div class="project-card">
  <h3>Marketing site redesign</h3>
  <a href="/projects/12/issues" aria-label="View issues for Marketing site redesign">View issues</a>
</div>
<div class="project-card">
  <h3>Mobile app v2</h3>
  <a href="/projects/13/issues" aria-label="View issues for Mobile app v2">View issues</a>
</div>

Each link now announces a distinct, fully identifiable name in a links list (“View issues for Marketing site redesign” versus “View issues for Mobile app v2”), while the visible card design, with its short “View issues” text next to each project heading, doesn’t change at all.

Common Mistakes

Mistake: “The link makes sense on the page, so it’s fine.” This is true only for a sighted user reading the page in its normal visual order. Screen reader navigation modes routinely present links, buttons, and headings as flat, context-free lists specifically because many users navigate that way, so a label that only works with visual context around it fails those modes completely.

Mistake: “This is the same problem as generic link text like ‘click here.’” They’re related but distinct. Generic text fails in every context, visual or not; nobody can tell where “click here” goes even reading the full paragraph around it. This rule covers text that’s genuinely fine in context and only breaks once that context is stripped away by an assistive-technology navigation shortcut.

Mistake: “I’ll fix this by making every link’s visible text unique instead of using aria-label.” That works too, but often at a real design cost: a card layout built around a short, consistent “View issues” or “Edit” label loses its visual consistency if every instance has to spell out the full subject on screen. aria-label solves the accessibility problem without forcing that visual tradeoff.

How RedFlag Detects This

AI-assisted: flagged by the optional Review Labels feature. RedFlag’s label-review workflow surfaces candidate elements where repeated, short interactive text appears across multiple instances on a page with no disambiguating aria-label, and a human reviewer confirms whether the repetition is genuinely ambiguous before it’s recorded as a violation. This is a hybrid flag-then-confirm process, not a deterministic DOM rule; RedFlag does not run an automated, code-only check for this pattern on every scan the way it does for rules like missing labels.

False negative: a reviewer who doesn’t personally test the page’s links list in a screen reader can miss genuinely ambiguous repeated labels that don’t visually stand out during a manual review pass. False positive: two elements with matching text that are, in fact, adequately disambiguated by an existing aria-label or by genuinely being duplicate links to the same destination can be flagged for human review unnecessarily. Manual step: the reviewer’s own judgment is the detection mechanism here, so confirm by actually opening a screen reader’s links or buttons list and checking whether flagged entries are distinguishable.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or JAWS running.
2. Pull up the links or buttons list (NVDA/JAWS: Insert+F7).
3. Scan for any text that repeats more than once, such as “View issues,” “Edit,” or “Renew,” and count how many entries share identical text.
4. For each repeated entry, ask whether you could tell, from the list alone with no other page context, which specific item it belongs to. If not, it fails.

Related WCAG Success Criteria

2.4.6 Headings and Labels: Headings and labels must describe topic or purpose. A label that only communicates its purpose with visual context stripped away, exactly what happens in a links list, fails the “describe purpose” requirement in the specific context assistive technology navigation creates.

Related Issues

Label doesn’t make sense in context is the closely related sibling check: single-word action labels like “Close” or “Submit” that give no context on their own, rather than repeated multi-word labels ambiguous only when duplicated.

Link text is generic and gives no context covers link text that fails everywhere, visual context or not: the more severe version of the same underlying “does this label communicate anything” question.

Multiple links with the same text point to different destinations is the axe-core automated check closest to this rule’s mechanism (matching link text pointing at different URLs), though this rule adds AI-assisted human review for cases the automated pattern match misses.

Heading text is vague or generic applies the same “describes purpose out of context” question to headings instead of links and buttons, under the same WCAG criterion.

Alt text is a raw filename is a related labeling failure reviewed through the same AI-assisted label-review workflow, for images instead of interactive controls.

References

• W3C Understanding 2.4.6: Headings and Labels
• W3C Technique G131: Providing descriptive labels
• WebAIM: Links and Hypertext: Link Text