Links need accessible names
ZMD007ZemDomu reports supported <a> elements whose source provides no accessible name through link text, ARIA naming, or labeled descendant content.
What this rule catches
- Empty links and icon-only links with no supported accessible-name source.
- Supported text, aria-label, aria-labelledby, and labeled-image patterns that resolve to no usable name in the analyzed source.
What static analysis cannot prove
- Static analysis cannot prove that a link name communicates its destination or purpose in context.
- Names introduced by runtime content, localization, or third-party components may need rendered-DOM and screen-reader testing.
Standards classification and detection confidence
- Classification
- normative — The rule checks for a supported accessible-name source needed to communicate a link's purpose.
- Detection confidence
- context dependent — Empty resolved link names are detectable. Static analysis cannot judge whether the resulting name describes the destination in context.
Applicable WCAG 2.2 criteria
Criterion 2.4.4 requires each link's purpose to be determinable from its text or programmatically associated context.
Normative means the rule checks a machine-testable part of a cited standards requirement. Advisory means it enforces a documented authoring convention or supporting technique. Neither classification makes a ZemDomu result proof of WCAG conformance.
Examples
✅ Good
<a href="/privacy">Read our Privacy Policy</a>
<a href="/settings" aria-label="Settings"><svg aria-hidden="true"></svg></a>
<a href="/home"><img src="/logo.svg" alt="ZemDomu home"></a>❌ Bad
<a href="/privacy"></a>
<a href="/settings"><svg></svg></a>React and Vue notes
- React/TSX
- Visible JSX text and static ARIA naming values can provide the name; expression-derived names may require rendered testing.
- Vue
- Visible template text and static ARIA naming values can provide the name; names supplied through reactive bindings may require rendered testing.
Quick summary
When: An <a> has no accessible name (no text, no aria-label/aria-labelledby, and no labeled content like img alt)
Warning: Link missing accessible name
Solution: Provide visible text or an accessible name via aria-label/aria-labelledby or labeled content (e.g., img alt)
Why it matters
Accessibility: Links without accessible names are announced without context, preventing screen-reader users from understanding link purpose.
SEO: Non-descriptive links offer little keyword context to search crawlers, reducing link value.
Rule details
In brief
- Goal: Make link destinations clear from each link's accessible name.
- What to do: Provide visible text, aria-label/aria-labelledby, or labeled content (like img alt) for each <a>; avoid empty anchors or vague phrases.
- Why: Users rely on link names to decide whether to follow them; empty or unlabeled links provide no context.
Intent
Prevent ambiguous or unnamed anchors so that assistive technologies can accurately convey link purpose, including icon-only links.
Benefits
- Screen-reader users can list and activate links based on meaningful names.
- Keyboard-only users understand where each link leads without surrounding context.
- Search engines index link names as part of page relevance signals, boosting SEO.
Techniques
H30: Use <a> text that clearly describes its target per WCAG 2.4.4.G203: Ensure the link's accessible name provides enough context to stand on its own.
HTML Semantics
The anchor's accessible name comes from its text content or from aria-label/aria-labelledby and labeled descendants like img alt; it must describe the hyperlink's function or target.
References
Tips & edge cases
- Avoid vague texts like “click here” or “learn more”; instead, describe the destination.
- Use unique link names for different links—even if they point to the same URL—to reduce confusion.
- For icon-only links, prefer visually hidden text or aria-labelledby to visible text elsewhere; use aria-label if there is no other option.
Related guides
Last verified: