Accessible web links

Let’s take a dive into using links in our web applications.

WCAG requirements

The Web Content Accessibility Guidelines detail that we need to make sure the purpose of each link can be determined.

The success criterion 2.4.4 for Level A compliance regarding link purpose in context:

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

In HTML, information that is programmatically determinable from a link in English includes text that is in the same paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.

The success criterion 2.4.9 for Level AAA compliance regarding purpose being evident via only the link itself:

A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

Additionally the link needs to be discernible. Link text must have a 3:1 contrast ratio from the surrounding non-link text. The link must also present a “non-color designator” (typically the introduction of the underline) on both mouse hover and keyboard focus. These two requirements help ensure that all users can differentiate non-link text from links, even if they have low vision, color deficiency, or have overridden page colors.

Make sure the size of your touch targets are compliant with WCAG standards. Someone with cerebral palsy, for example, may be able to use their hands to manipulate a mouse, but may have difficulty with the precise movements and muscle control necessary to click on a small link.

The success criterion 2.5.5 for Level AAA compliance regarding touch target sizes states:

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

Anatomy of an anchor tag

HTML anchor elements must have a non-empty href attribute in order to be considered true links and to be accessible to keyboard users.

Some sites use a link with “#” as the href value which opens a dropdown of more links on hover or click. This isn’t ideal. Instead we should create a page where everyone can navigate to by clicking the link in order to access the same sub links available in the dropdown.

When images are used as links, the alternative text performs the function of link text. The alternative text should convey the content of the image and the function of the link. If a linked image does not have alternative text, a screen reader may read the image file name or the URL being linked to.

Link content clarity

URLs are not always human-readable or screen-reader friendly. Many URLs contain combinations of numbers, letters, ampersands, dashes, underscores, and other characters that make sense to scripts and databases but which make little or no sense to the average person. In most cases, it is better to use human-readable text instead of the URL. If the URL is relatively short (such as a site's homepage), the URL is usually fine to be used as the link text.

Short, concise links are less likely to frustrate screen reader users than long, imprecise links. However, links are more useful when they make sense out of context. Authors should avoid non-informative link phrases such as “click here”.

Nearly any time a:hover (or other hover effects) are defined in CSS, it should be modified to be a:hover, a:focus to ensure the same visual presentation is available when keyboard users navigate or “tab” to the link.

In-page links should generally be presented so it is visually and/or contextually apparent that they are in-page links.

When using a screen reader, it can sometimes be a little difficult to tell when one link ends and where an adjacent link begins. JAWS says "link" before each link, which minimizes this problem, but it can be a little more difficult with other screen readers. One solution is to provide a non-link character between each link. The vertical bar ( | ) is used quite often for this purpose. Another solution is to put the links in an ordered or numbered list. Screen readers tend to pause between list items, helping the user audibly distinguish between separate links.

Authors can designate links that open in new tabs/windows by placing this information in parentheses at the end of the link, for example by saying "Biographical sketch (opens new window)." or by using an appropriate image within the link text.

Place the distinguishing information of links at the beginning of a link. Don't put extra information first. For example, don't use a link with display text, "Link opens in a new window: Products." Instead, use a link with display text, "Products (opens in a new window)".

Users should generally be alerted to links that lead to non-HTML resources, such as PDF files, Word files, PowerPoint files, and so on. When identifying the link file type, this additional content should be presented inside the link, rather than just after it, so that the information is presented with the link if a screen reader user navigates by links or reads a link list.

<!-- use -->

<a href="1099.pdf">Tax form 1099 (PDF)</a>

<!-- rather than -->

<a href="1099.pdf">Tax form 1099</a> (PDF)

If you walk away with nothing else

Please try to think of every possible user when including links in your content.

Let’s attempt to understand and follow the Web Content Accessibility Guidelines when building our applications. Something so simple like adding a link correctly can have an extremely positive effect on the user experience of your app.