Guideline: Link Text

The purpose of a link should be clearly recognisable on the screen. Screen reader users should also be able to determine it easily. This is done either by naming the purpose directly in the link text or by means of the technical context. The Web Content Accessibility Guidelines (WCAG) 2.0 specify corresponding requirements for accessible design. The above methods correspond to WCAG 2.0 conformity level A. Only at the highest conformity level AAA must the link purpose be evident from the link text alone, without including the context.

Technical Context

The screen reader technique works basically like this: Web pages are tabbed through using the tap-key, focusing on links and other active elements. The screen reader outputs the focused elements either by speech or with the help of a Braille display.

Example:

<h2><a href="article.html">A Heading</a></h2>
<p>A Teaser Text.</p>
<p><a href="article.html">more</a></p>

The purpose of the first link is evident from the link text. With the second link, on the other hand, the purpose is not clearly recognizable without the context, since here the link text consists only of an undefined "more". With a screen reader, it is not clear whether the link belongs to the previous or subsequent text.

A simple solution to meet the minimum accessibility requirement is to include the link in the paragraph:

<h2><a href="article.html">A Heading</a></h2>
<p>A Teaser Text. <a style="display:block;" href="article.html">more</a></p>

The link text is still ambiguous, nevertheless is it now possible for the screen reader user to determine the link purpose with a keystroke. For example, by reading aloud the paragraph containing the link. Another possibility would be changing the order of the elements:

<h2><a href="article.html">A Heading</a></h2>
<p><a href="article.html">more</a></p>
<p>A Teaser Text.</p>

However being still ambiguous, the technical context (e. g., the immediately preceding heading) ensures that a screen reader user can determine the purpose of the "more" link.

These and numerous other techniques for establishing technical context for links are documented at the WCAG.

Unambiguous Design of Link Texts

Accessible Rich Internet Applications (ARIA) 1.1, a W3C web standard, changes the specification for browsers on how to store which texts in the accessibility tree of the respective operating system (this is where screen readers pick up the information and process it further). Especially for dynamic web pages, ARIA enables better accessibility by adding information about roles, properties and states. There are new attributes, such as "aria-label", but also changes, for example, for the title attribute, which is expected to re-specify the algorithms for determining a link text (this document is a work in progress).

For all browsers, the link text consists of an accessible name, an accessible description, and a help text. The teaser example above can also be made WCAG 2.0 compliant by adding a description to the name:

<h2><a id="description text" href="article.html">A Heading</a></h2>
<p>A teaser Text.</p>
<p><a aria-describedby="description text" href="article.html">more</a></p>

The second link text is composed of the name of the second link "more" and a description (in this case the link text of the first link) and is now clear with "more A Heading" for screen reader users.

Please not, that ARIA is to be used as a makeshift. It is more practical to use a link text that describes the link purpose from the beginning:

<h2><a href="artikel.html">A Heading</a></h2>
<p>A Teaser Text.</p>
<p><a href="article.html">[Subject] in detail</a></p>