Link Accessibility – Colors Are Not Enough

According to a less frequently mentioned accessibility principle, hyperlinks inside text blocks shouldn’t be solely distinguished by color. Not only because users with low vision, color deficiency, and other visual impairments can’t always recognize these links, but it’s also easier for regular users to skim through the content if links are better emphasized.

However, it’s not always easy to find a good solution for link design, that doesn’t harm aesthetics. And, it’s also possible to overdo link design by using too many signifiers that confuse the user.

Body text links

When we speak about links, we usually think of the classic blue links with the underline, however there are actually different kinds of links on most websites. I’ve found these main types:

  1. Body text links
  2. Headline and subtitle links
  3. Menu links
  4. Buttons
  5. Image links
  6. Video links
  7. Audio links

In this article, I will only examine the first group, body text links. Don’t read it as a guideline but rather as an experiment for understanding what can be done for better link accessibility.

What WCAG 2.0 says

Ironically, the WCAG 2.0 docs (accessibility guidelines of the W3C) are not very well structured, so I rather use WebAIM’s guideline on links and hypertext, that’s much easier to search.

According to the section, WCAG 2.0 has two additional requirements for body text links:

  1. The link text must have a 3:1 contrast ratio from the surrounding non-link text.
  2. The link must present a “non-color designator” (typically the introduction of the underline) on both mouse hover and keyboard focus.

Default browser styling

Browsers have a default styling that you can check for any web page by disabling all styles with the Web Developer Toolbar.

Example: Chrome’s default link styling

For instance, this is how the homepage of the Mozilla Developer Networks looks like in Chrome:

Basic Chrome styling

It’s a very basic styling for sure, but it’s still styling: the underlined blue links are well-known and easily recognizable by internet users. It’s not a coincidence that the Nielsen-Norman Group also considers blue the safest link color choice (see the related Beyond Blue Links: Making Clickable Elements Recognizable article).

Non-color designators

Underline

WebAIM doesn’t recommend to remove the underline using CSS, as “users are accustomed to see links underlined”. Sadly, many of the biggest websites don’t follow this principle through and they don’t only remove the underline from the default link style but also from the :hover state.

Why do they do so? Most likely for aesthetical reasons, however underlined links don’t necessarily have to be plain-looking.

Example: Bloomberg

For instance, Bloomberg uses the border-bottom CSS property to mimic an underline—but in a different color (link text is black, underline is blue).

Bloomberg border bottom as link signifier Perhaps Bloomberg’s links could further benefit from bold letters, but it’s a good example that underline can be used for links creatively, not just the usual way.

Example: The Verge

The Verge has a different approach to body text link underlines. The underline is present at the default state, however it’s removed on hover. Parallelly with the removal of the underline, the color also subtlely changes, from pink to magenta (however this color change is barely recognizable).

Underlined links in The Verge

The presence of the underline in the default state helps readers easily notice the link. And, when they hover the link, the state change is instantly visualized by the disappearing underline. An unusual choice, for sure, but, in fact, follows the accessibility principle of non-color designators.

Icons

You can also help users recognize links by adding tiny icons next to them. For example, some news sites add a video starting icon next to body text links that lead to videos (however, these days embedding videos is a more widely used practice).

Example: WebAIM

For a better example, WebAIM adds a small icon after all external links. This is an excellent practice, not simply because the icon serves as an extra visual signifier, but also because external links are distinguished from internal links in an elegant way.

WebAIM external link icon

Font Awesome also has an external link icon you can quickly add to your external links.

Font Awesome external links

Link text

As screen readers notify users when they come across a link, it’s not recommended to use phrases like “link to” or “follow this link” in the link text.

However, providing a link text that describes the purpose of the link helps accessibility, especially because content shouldn’t only be made accessible to screen reader users but also to users with different cognitive disabilities.

WCAG 2.0 even has a recommendation on how to provide proper link texts, with a handful of useful examples (mainly for image links, though).

Example: Gov.uk

If you want an example for properly done link text I would mention the Gov.uk website that publishes governmental information in the UK. For instance, have a look at their “Set up a business” page.

Gov.uk Link Texts

Have a look at, for instance, the “Find out more about being a sole trader and how to register” line. Note how they put the anchor tag on the part that describes the purpose of the link, and not on the action verb (i.e. “Find out more”).

The title attribute

The role of the title global attribute in link accessibility is an interesting question. When you add it to a link, the extra information appears on hover somewhere around the link.

For instance, the following line of code:

<a href="#" title="Extra information">Hover this link, don't click it.</a>

looks like this: Hover this link, don’t click it.

I’ve long thought that adding the title attribute to links is a good practice for accessibility, as the extra information helps users understand the purpose of the link. Moreover, when the title label appears on hover, it clearly indicates the presence of a clickable element. However, WCAG 2.0 has a slightly different view on the question.

In their “Supplementing link text with the title attribute” document, they mention several accessibility problems. For example, the content of the title attribute isn’t available to assistive technology users, and it also disappears after about five seconds in most user agents.

On the whole, WCAG 2.0 doesn’t advise against the usage of the title attribute in links but calls for cautious usage. One thing is sure, don’t use title for important information that is not available otherwise, such as warnings. However, it’s another question that if it can only be used for unimportant information is it worth using at all?

Link states

There are five different link states, represented by CSS pseudo-classes (click the links below for documentation).

  1. :hover
  2. :focus
  3. :active
  4. :visited
  5. :link

It’s also an open question whether it is better for accessibility to style all link states differently or not. If you use different style rules for each state users are notified about every change, however is that always a good thing? Too many state changes can cause information overload confusion to the user.

I tend to follow the “indicate the user interaction” principle, which means I use one style for the default link state and another one for the :hover, :active, and :focus states, but I can’t tell if this is the best solution for accessibility. If you are interested in the topic more, have a look at this StackOverflow UX discussion on whether the styling of :focus and :hover should be the same or distinct.

However, there’s an important thing you should follow by any means. Don’t remove the dotted outline that browsers use for the :focus state, as tab navigation needs it to make the focused element visible. If you remove it keyboard users lose focus (literally). If you’re annoyed by the default outline style make it less obtrusive with extra styling, but don’t remove it.