Usability & Web Accessibility – Links

Posted by Yale University | Date Accessed: August 15, 2022

Download the Link Accessibility for Content Editors training slides(link is external).

Table of Contents

1. How People with Disabilities Use Links
2. Link Text
   1. Fallbacks
3. Image Links
4. Adjacent Links
5. Designing Links
   1. Non-Color Indicators
   2. Focus Styles
   3. Other Design Considerations
6. Developer Techniques
   1. Combine Adjacent Links into a Single Link
   2. Hidden Link Text
   3. ARIA Techniques
   4. Emulating Links

How People with Disabilities Use Links

While screen readers can read a full page to a user, screen reader users may prefer to instead listen to a list of links. In that case, a screen reader may only read the link text and not the surrounding text.

Speech recognition software allows a user to avoid using a mouse. Users can speak the text of the link that they would like to follow.

Keyboard-only users may not be able to use a mouse to click links. They use a keyboard’s tab button to navigate through a page’s links, buttons, and form inputs. For such users, it is very important for them to see which item has focus at all times.

Colorblind users may not be able to perceive color cues. Typically, pages present links as a different color than their surrounding text. Adding underlines or other non-color indicators help users who may not see color. Users who are not comfortable with technology may also appreciate having links underlined.

Link Text

It’s most important for link text to make sense without the surrounding sentences or content. The link text alone should convey the function and purpose of the link. Link text should also be unique and easy to speak out loud.

Consider these guidelines when writing link text:

• Avoid link text like “Click Here,” “More,” and “Read More.” These kinds of links can be confusing when a screen reader reads them out of context.
• Use unique link text where possible. Speech recognition software users may have a bad experience with duplicated link text.
• It is OK to link a full sentence, but avoid longer.
• Use judgment when linking full URLs. When linking a URL, consider users who must speak it out loud and who must listen to a screen reader announce it.

Fallbacks

Occasionally, it may not be possible to make link text alone convey the link’s purpose out of context. In those cases, a few fallback strategies are available:

• The link together with the surrounding sentence, paragraph, or list item should be enough to convey a link’s meaning or purpose.
• You may give more context through the link’s title attribute.

These approaches create a worse experience for users with disabilities, so they should a last resort.

Image Links

In general, content editors should avoid using images as links. If an image functions as a link, the image must have alt text that conveys the location and purpose of the link. The alt text should not describe the image. Treat image links as links, not as images.

Adjacent Links

Pages should not present more than one link to the same destination next to each other. One common design pattern is for an image, a heading, and a word like “More” to each link to the same destination, such as in a news list. Assistive technology users may find navigating through several links a bad experience. Instead, provide one link. Either select one element to be the link, or wrap all elements within one link.

Designing Links

Non-Color Indicators

Giving links a different color from the surrounding text is common on the web. Color differences help sighted users, especially users with cognitive impairments. But, color differences alone are not sufficient for accessibility.

In general, pages should have some non-color away of conveying links. This concern applies most to links that appear alongside or within blocks of text. Links that appear in menus, for example, are clear enough because of their place in a layout.

The easiest way to provide non-color link indicators is by underlining links. The underline should always be persistent, not solely on hover. Another common option includes having an icon.

Some designers prefer not to have a non-color indicator be present only on hover. While the WCAG guidelines allow for this, the requirements are extremely stringent:

• A non-color indicator, such as an underline, must be present on hover
• The contrast ratio between the surrounding text and the background must be at least 4.5:1
• The contrast ratio between the link and the background must be at least 4.5:1
• The contrast ratio between the link and the surrounding text must be at least 3:1.

In practice, there are very few color combinations that meet the above requirements. Even then, such designs provide a worse experience for colorblind or cognitively impaired users.

Focus Styles

Keyboard-only users press the tab key to navigate through interactive elements like links. As such, it is important that users be able to see which element is currently has keyboard focus.

Each browser has a different default focus style, generally a thin dotted line or faint blue ring. Browser defaults are often imperceptible, especially around image links or on blue backgrounds. As a general rule, designers should design custom focus styles. Focus styles should be noticeable and salient.

Other Design Considerations

Link sizes should be generous. Large link sizes make it easier for users with low coordination or on mobile devices to activate links. Link size consideration is most important for links that are not contained within blocks or paragraphs of text, such as call to action links. Links should be at least 44px wide and 22px tall.

Links should not be too large on mobile. Very large links that take up much of the viewport can be accidently activated, such as when a user touches the screen to scroll up or down.

Many designers provide hover styles to give extra cues when a mouse is over a link. Such styles may include a background color, glow, outline, or brief animation. Providing these styles is a best practice. When providing hover styles, it is also best to provide them on keyboard focus.

Developer Techniques

Combine Adjacent Links into a Single Link

It’s common for pages to present multiple links to the same location next to one another. For example, a news listing may present an image, heading, and “more” text each as links to the same story. This can create a bad experience for assistive technology users.

sInstead, wrap all elements within the same anchor tag. Doing so provides a larger clickable area, a single tab stop for keyboard-only users, and a single entry for screen reader users. A screen reader will read all content within the a tag. So, images contained in this kind of anchor should have a null alt attribute.

Developers should take care when styling such anchor tags. Applying display:block on the anchor element may make styling easier. When styling for hover and focus, CSS can target elements within the focus. For example, to underline text within an anchor on focus, use a:focus p {text-decoration: underline;}.

Hidden Link Text

As a general rule, link text alone should be enough to convey the purpose of the link. But, some visual designs do not allow for descriptive link text. One strategy for dealing with such designs is to include extra text within a span inside the link. Developers can use CSS to hide the extra text visually but still expose it to screen readers.

Developers should use care when providing such screen reader-only text. The following techniques will hide content from screen readers altogether and should be avoided when providing screen reader-only content:

• CSS: visibility: hidden;
• CSS: display: none;
• CSS: width: 0px; height: 0px
• HTML’s hidden attribute

To hide text visually but make it accessible to screen readers, use the following CSS:

clip: rect(1px 1px 1px 1px); /* IE 6/7 */
clip: rect(1px, 1px, 1px, 1px);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;

For more see:

• Beware smushed off-screen accessible text (link is external)
• HTML 5 Accessibility Chops: hidden and aria-hidden (link is external)
• Invisible Content Just for Screen Reader Uses(link is external)

ARIA Techniques

Besides the hidden link text approach discussed above, ARIA provides HTML attributes developers may want to consider: aria-describedby, aria-label, and aria-labelledby.

The aria-describedby attribute provides extra text for a screen reader besides the link text. To give a link an ARIA description, first give the descriptive text an id attribute. Then, give the link an aria-describedby attribute equal to the description’s id attribute. A screen reader will first read the link text, then the description. For example:

<a aria-describedby=”foo”>Some link text”</a>
<p id=”foo”>A description for the link</p>

When encountering the link, a screen reader will read “Some link text A description for the link”.

The aria-decribedby attribute should often be a developer’s preferred implementation. Developers can also create ARIA labels the using aria-label and aria-labelledby attributes.

Assistive technology considers an ARIA description to be in addition to the link text. But, assistive technology considers an ARIA label to replace the link text. For that reason, links with ARIA labels may create a worse experience for speech recognition software users. If the ARIA label does not match the link text at least in part, speech recognition software may not work as a user expects.

To use the aria-label attribute on a link, set the aria-label equal to the label directly. For example:

<a aria-label=”My ARIA label”>Some link text”</a>

To use the aria-labelledby attribute on a link, first provide some other text an ID attribute. Then, give the link an aria-label equal to that other text’s id attribute. For example:

<a aria-labelledby=”bar”>Some link text</a>
<p id=”bar”>My ARIA label</p>

In both cases, a screen reader would read “My ARIA label.” A screen reader would never read “Some link text.”

Emulating Links

When creating links, developers should use the <a> tag. The <a> tag has important accessibility features built in by default. It is keyboard focusable, and screen reader will announce the link as a link. By default, the hover mouse cursor style is set to a pointer, instead of the default arrow.

Developers can emulate links with other elements, such as <div> or <span> elements and JavaScript click listeners. But, these kinds of emulated links need care. Developers wishing to emulate links must include the following:

• Add tabindex=”0” so that the link becomes keyboard focusable
• Add role=”link” so that assistive technology recognizes the element as a link
• Add the styling cursor: pointer so that mouse users will recognize the element as a link.

For example, the markup for an accessible emulated link might look like the following:

<span role=”link” tabindex=”0” style=”cursor:pointer;text-decoration:underline;color:blue;”>This is an emulated link</span>

To avoid needing to implement the above, developers should prefer to use the <a> tag instead.

About This Article:

A Life Worth Living has copied the content of this article under fair use in order to preserve as a post in our resource library for preservation in accessible format.  Explicit permission pending.

Link to Original Article: https://usability.yale.edu/web-accessibility/articles/links