Is each link explicit (except in special cases)?

A screen reader user often navigates by the document's link list, a command that extracts each link from its context. If this list displays "Learn more" twenty times, it is unusable. Generic label, invisible destination.

Criterion 6.1 accepts two levels of conformity. The label alone: what the screen reader announces when browsing links in isolation. The link context: the preceding section title, the parent paragraph, or the table header. A link "Read the article" under an <h3> titled "Mobile accessibility" is RGAA-compliant. In the link list, that same link becomes opaque.

Five types of links are covered: plain text, image (the text alternative provides the label), composite (combination of text and image alternative), SVG (accessible name resolved from the content of the <svg> element), and links where the accessible name must contain the visible text (test 6.1.5, linked to SC 2.5.3 for voice input).

When possible, aim for WCAG SC 2.4.9 level AAA: each link explicit without recourse to context. It is the only solution that works in all navigation modes, with all screen readers, and for voice input users.

5 tests to verify that each link is explicit out of context

Link text with explicit label or context

  1. Identify all links whose content is text only (no image, no SVG).
  2. For each link, read its label in isolation: do you know where it leads and what it does?
  3. If not, check the context: preceding section title (<h1> to <h6> in the same block), parent paragraph (<p>), or row or column header in a table.
  4. If neither the label alone nor the context allows understanding the link's destination and function → test fails.

Image link with explicit alternative text

  1. Identify links whose content is an image: <img>, element with role="img", <area href>, <object>, <canvas>, or <svg>.
  2. Identify the link's accessible label: alt attribute on the image, or aria-label or aria-labelledby on the link itself.
  3. Verify that this label (or the link context) allows understanding the destination and function.
  4. Image without alt, empty alt on a solo image link with no other text, or generic alt ("image", "logo" without detail) → test fails.

Composite link text and image explicit

  1. Identify links that contain both visible text and one or more images.
  2. Calculate the accessible label: it is the combination of visible text and alt attributes of images contained in the link.
  3. Verify that this combination (or the context) allows understanding the destination.
  4. If the link text is already explicit, the image must have alt="" to avoid repetition. If the image provides additional information, its alt must convey it.
  5. Combination of empty text and empty alt, or resulting label too generic without context → test fails.

<svg> link with explicit accessible name

  1. Identify <svg> elements containing an <a href> (SVG 2) or <a xlink:href> (SVG 1.1).
  2. Identify the accessible name of the SVG link: generally a <text> element inside the SVG, or an aria-label or aria-labelledby on the <a> element.
  3. Verify that this accessible name (or the context) allows understanding the destination.
  4. No <text>, no aria-label, no aria-labelledby on the link → test fails.

Accessible name containing visible label

This test verifies compatibility with voice input software (SC 2.5.3). A user activates a link by stating its visible label. If the accessible name does not contain this text, the voice command fails.

For non-SVG links:

  1. Identify links that have a visible label AND an aria-label, aria-labelledby, or title.
  2. Verify that the attribute indeed contains the link's visible text (case and punctuation may differ).

For SVG links: 3. Identify SVG links that have a visible label AND an aria-label, aria-labelledby, direct child <title>, xlink:title, or one or more <text>. 4. Same verification: the visible text must be present in the accessible name.

  1. If an attribute completely replaces the visible label without containing it → test fails.

Exceptions: if the visible label is a symbol (e.g., "B" for "Bold"), the accessible name must express the function, not repeat the symbol. Mathematical expressions (e.g., "A>B") can be repeated literally.

Examples

❌ Non-compliant : Repeated generic links, context not exploited

<article>
  <h2>RGAA Training</h2>
  <p>Learn the fundamentals of digital accessibility.</p>
  <a href="/rgaa-training">Learn more</a>
</article>
 
<article>
  <h2>Accessibility Audit</h2>
  <p>Evaluate your site's conformity.</p>
  <a href="/audit">Learn more</a>
</article>

In the screen reader's link list, the user hears "Learn more" twice. Impossible to distinguish destinations. The preceding <h2> does constitute valid RGAA context, but only if the user manually navigates to it. Not all screen readers automatically exploit this context.

✅ Compliant : Explicit links without context dependency

<article>
  <h2>RGAA Training</h2>
  <p>Learn the fundamentals of digital accessibility.</p>
  <a href="/rgaa-training">Discover RGAA training</a>
</article>
 
<article>
  <h2>Accessibility Audit</h2>
  <p>Evaluate your site's conformity.</p>
  <a href="/audit">Request an accessibility audit</a>
</article>

Each link is understandable in isolation. In the screen reader's link list, both destinations are distinct. RGAA-compliant (SC 2.4.4) and WCAG AAA (SC 2.4.9).

❌ Non-compliant : Image link without text alternative

<a href="/home">
  <img src="company-logo.png">
</a>

Without an alt attribute, the screen reader announces the filename: "company-logo.png". The user does not know it is a link to the home page or what this link does. Test 6.1.2 fails.

✅ Compliant : Image link with explicit alternative

<a href="/home">
  <img src="company-logo.png" alt="Home - Acme Corporation">
</a>

The alt attribute provides the link's label. The screen reader announces "Link: Home - Acme Corporation". The destination is clear even out of context.

❌ Non-compliant : aria-label that replaces the visible label without containing it (test 6.1.5)

<a href="/report-2025.pdf" aria-label="Download the annual report">
  Report 2025
</a>

A voice input user says "Click on Report 2025". The command fails: the accessible name is "Download the annual report", which does not contain the visible text "Report 2025". Test 6.1.5 fails (SC 2.5.3).

✅ Compliant : aria-label that contains and enriches the visible label (test 6.1.5)

<a href="/report-2025.pdf" aria-label="Report 2025 - Download the annual report (PDF, 3 MB)">
  Report 2025
</a>

The accessible name begins with the visible text "Report 2025". The voice command works. Additional information (format, size) enriches the experience without breaking compatibility.

Tips and pitfalls

⚠️ RGAA context is not visual context

In RGAA, the "link context" is precisely defined: parent sentence (<p>), parent list element (<li>), preceding title in the same semantic block, column or row header in a table. Text that is visually close but has no direct semantic relationship does not count. A link separated from its title by another content element may lose this context. In an audit, check the DOM, not the visual layout.

⚠️ aria-label that overrides the visible label instead of enriching it

Adding a longer aria-label to clarify the destination is a good practice, provided the visible text is contained within it. The reflex: always start the aria-label with the visible text, then add the complement. "Report 2025 - download the PDF" works. "Download the 2025 report" if the visible text is "Report 2025" does not satisfy test 6.1.5.

⚠️ Link ambiguous for everyone: criterion not applicable

For tests 6.1.1 to 6.1.4, if the link is ambiguous for all users and not just for people with disabilities, the criterion is not applicable. This is the case of a link whose destination is deliberately mysterious by editorial design. Very rare in practice: most "generic" links are not ambiguous for everyone, just poorly written. Do not use this exception to justify non-conforming links.

⚠️ Symbols in test 6.1.5: function takes priority over label

If the visible label is a symbol, the accessible name must express the function, not repeat the symbol literally. The "B" of a text editor will have the accessible name "Bold". The ">" sign depending on context will mean "Next" or "Play video". Exception: mathematical expressions like "A>B" can be repeated literally in the accessible name, the user themselves making the correspondence with their voice input software.

💡 Prefer explicit label to context: it is more reliable

Context is RGAA-compliant but depends on the screen reader's implementation. Some users must enable an option for the context to be announced. Others navigate directly through the link list, where context does not appear. An explicit label works everywhere, without configuration. Invest 30 seconds to write "Learn more about RGAA training": it is worth it.

💡 Do not write "link" in the label

Screen readers automatically announce the role before the label. The user hears "Link: my blog". Writing "Link to my blog" in the visible text produces "Link: Link to my blog", redundant and disruptive. Same logic for "Click here to": the screen reader does not distinguish a link from a button via the label, so "click" adds nothing.

Frequently asked questions

Why does a "Learn more" link placed after an <h3> fail criterion 6.1 RGAA?

Yes, provided the link and title are in the same semantic block and the title directly precedes the link without intermediate elements that would break the context. This is compliance at the strict minimum of RGAA (SC 2.4.4). In the screen reader's link list, the link remains ambiguous. Prefer "Learn more about [topic]" or a fully explicit label.

How do you audit image links for RGAA criterion 6.1 in practice?

With developer tools, inspect each <a> whose content is an <img>, an SVG, or an element with role="img". Verify: (1) the image has a non-empty and descriptive alt, or (2) the link bears an explicit aria-label or aria-labelledby. Includdy automatically flags image links without accessible text. Attention: empty alt (alt="") is non-compliant on a solo image link because it deprives the user of any label.

In what cases does an aria-label longer than the visible label respect test 6.1.5 RGAA?

Yes, provided the visible label is contained in the aria-label. Case and punctuation may differ. Visible label "report 2025" and aria-label "Report 2025 - Download the report (PDF, 3 MB)" is compliant. Conversely, aria-label "Download the annual report" without "2025" fails because the voice command "Click on Report 2025" finds no match.

What is the difference between RGAA criterion 6.1 and WCAG SC 2.4.9?

Criterion 6.1 is based on SC 2.4.4 (level AA): the link's context is allowed to make the link understandable. SC 2.4.9 (level AAA, outside RGAA scope) requires that the label alone be sufficient, with no recourse to context. A "Learn more" link with a section title satisfies RGAA but fails AAA. Aim for 2.4.9 when possible: it is the level that benefits all users.

Why does a link whose text is a raw URL fail criterion 6.1 RGAA?

No, unless the URL is itself understandable ("accessibility.numerique.gouv.fr" may be acceptable in some contexts). A technical URL ("https://example.com/p?id=4827") is not an explicit label: nobody understands the destination. Replace it with descriptive text. This is one of the most frequent errors in documents exported from PDF to the web.

References

RGAA 4.1.2: Criterion 6.1
WCAG 2.1:1.1.1 (A)2.4.4 (A)2.5.3 (A)H30H78H79H80H81G53G91F63F89ARIA7ARIA81.1.1 (A)2.4.4 (A)2.5.3 (A)