Links must have discernible text

Rule ID: link-name
Ruleset: axe-core 4.10
User Impact: Serious
Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), WCAG 2.2 (A), Section 508, Trusted Tester, EN 301 549
 

Learn Web Accessibility

Subscribe to our extensive curriculum of online self-paced courses

Compliance Data & Impact

User Impact

Serious
▼
Minor
Critical

Disabilities Affected

  • Blind
  • Deafblind
  • Mobility

Standard(s)

  • WCAG 2.1 (A)
  • WCAG 2.0 (A)
  • WCAG 2.2 (A)
  • Section 508
  • Trusted Tester
  • EN 301 549

WCAG Success Criteria [WCAG 2.1 (A)]

  • 2.4.4: MUST: Link Purpose (In Context)
  • 4.1.2: MUST: Name, Role, Value

WCAG Success Criteria [WCAG 2.0 (A)]

  • 2.4.4: MUST: Link Purpose (In Context)
  • 4.1.2: MUST: Name, Role, Value

WCAG Success Criteria [WCAG 2.2 (A)]

  • 2.4.4: MUST: Link Purpose (In Context)
  • 4.1.2: MUST: Name, Role, Value

Section 508 Guidelines

  • 1194.22: MUST: Web based intranet and Internet Information & Applications
  • 1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content)

Trusted Tester Guidelines

  • 6.A: MUST: The purpose of each link or button can be determined from any combination of the link/button text, accessible name, accessible description, and/or programmatically determined link/button context.

EN 301 549 Guidelines

  • 9.2.4.4: MUST: Link Purpose (In Context)
  • 9.4.1.2: MUST: Name, Role, Value

How to Fix the Problem

  • Ensure that all link names are accessible. It may be possible that the inner link text is not visible to a screen reader, that there are duplicate link labels, or that the link is not focusable.

  • Ensure all links can receive programmatic focus; for example, avoid device-specific events (for example, onmouseover).

  • To ensure all link text is visible to screen readers, link text cannot be hidden (e.g. with display: none or aria-hidden="true").

  • To ensure all links can receive programmatic focus, avoid device-specific Javascript events such as onmouseover(), mouseover(), hover(), onmouseout(), mouseout(). Replace these with device-independent events such as onfocus(), focus(), onblur(), or blur().

  • Do not modify the style of the links to suppress the change in style when a link is the object of programmatic focus. Modifying link styles removes the capability for sighted keyboard users to know where they are on the page. Furthermore, ensure you are creating real links using the a element with the href attribute.

The ARIA 1.1 Wiki Using aria-label for link purpose page provides the following example to describe the purpose of a link in HTML using the aria-label element: 

<h4>Neighborhood News</h4>
 <p>Seminole tax hike: Seminole city managers are proposing a 75% increase in 
 property taxes for the coming fiscal year.
 <a href="taxhike.html" aria-label="Read more about Seminole tax hike">[Read more...]</a>
 </p> 
 <p>Baby Mayor: Seminole voters elect the city's youngest mayor ever by voting in 3 year
 old Willy "Dusty" Williams in yesterday's mayoral election.
 <a href="babymayor.html" aria-label="Read more about Seminole's new baby mayor">[Read more...]</a>
 </p>

Why it Matters

  • Inaccessible link elements pose barriers to accessibility, as they are a fundamental component of a website.

  • Users who rely exclusively on a keyboard (and no mouse) to navigate a webpage can only click on links that can receive programmatic focus. A link that cannot receive programmatic focus is inaccessible to these users.

  • Like sighted users, screen reader users need to know where a link is pointing. Inner link text provides this information, though it won't get used if a screen reader can't access it.

  • Keyboard users, including visually impaired screen reader users or people who cannot use a mouse, can activate only the links and form elements that can receive programmatic focus. Any events activated exclusively by other types of focus, for example onmouseover events that depend on the mouse hover focus, are inaccessible to keyboard users. Only links and form elements receive keyboard focus by default. Modify elements that are not links or form components to receive focus by adding tabindex="0".

Rule Description

Link text and alternate text for images, when used as links, must be discernible by a screen reader, must not have a duplicate label, and must be focusable.

The Algorithm (in simple terms)

Ensures that every link has an accessible name.

Resources

Deque University Course Pages (subscription required)

Contribute to axe-core on GitHub

Other Resources

You may also want to check out these other resources.

Refer to the complete list of axe 4.10 rules.

Was this information helpful?

You have already given your feedback, thank you..

Your response was as follows:

Was this information helpful?
Date/Time feedback was submitted: