Confirm that all hyperlink elements have meaningful, discernible text content

What This Rule Checks

Every link on a webpage must have a clear and discernible name that describes its purpose or destination. This ensures that users who rely on assistive technologies, such as screen readers, can understand the link’s purpose without needing to guess. Links that are identified solely by ambiguous text such as “Click Here” or “Read More” without further context create accessibility barriers.

For example, instead of using “Click Here,” a better link name would be “Read the full article on climate change” to give users a clear sense of what the link leads to.

Who Is Affected

This issue primarily affects: Blind users, who rely entirely on screen readers or braille displays to navigate and interact with content; Deafblind users, who rely on braille displays and cannot access visual or auditory content; Mobility users, who navigate using keyboards, switches, voice control, or other assistive input devices.

Why This Matters

Screen reader users often navigate by pulling up a list of all links on the page. Links named “Click here” or “Read more” become meaningless in this context. This violates WCAG 2.4.4 (Link Purpose in Context) and is a top-cited violation in lawsuits.

How to Fix

Use Descriptive Link Text:

Ensure that the link text itself is descriptive and provides context. Avoid vague text like “Click Here” or “Read More” without additional context.

Use aria-label for Additional Context:

If you need to provide more information for screen readers while keeping the visible text short, use the aria-label attribute.

Use aria-labelledby to Reference Other Text:

If the link requires further explanation, use aria-labelledby to point to another element that provides context.

Make Sure Link Text is Accessible to Screen Readers:

Avoid hiding link text from screen readers by using styles like display: none or aria-hidden=”true”. The link text must always be visible to screen readers.

Ensure Links Can Receive Programmatic Focus:

All links should be focusable by keyboard navigation, not just via mouse interactions. Avoid using device-specific JavaScript events like onmouseover or onmouseout. Instead, use device-independent events like onfocus() and onblur() to ensure accessibility for all users.

Maintain Visual Focus Indications:

Do not modify the default styles for links when they receive focus. Removing or suppressing the focus state makes it difficult for sighted keyboard users to know where they are on the page.

Ensure Links Use Proper HTML:

Always create real, functional links using the <a> element with the href attribute. Do not use non-semantic elements or JavaScript to create links unless absolutely necessary.

Code Examples

Common Mistakes to Avoid

• Using “Click here”, “Read more”, or “Learn more” without additional context.
• Creating links with only an icon and no text alternative.
• Using the same link text for different destinations on the same page.
• Wrapping block-level content in links without providing a concise accessible name.

AI Auto-Fix Available

This rule supports ACE™ AI Auto-Fix. When a violation is detected, ACE can automatically generate a code fix for review. The AI analyzes the specific element in context and proposes a targeted remediation that preserves your existing markup and styling. You can preview, modify, and approve the fix before it is applied.

Tip: Keyboard navigation is essential for users who cannot use a mouse. Ensure all interactive elements are reachable via the Tab key and operable via Enter or Space. Test focus visibility and focus order on every page.

Related WCAG Criteria

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