Link accessibility – Colors are not enough

How to make hyperlinks accessible for everyone

Posted by Anna Monus on October 06, 2017

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 matches your website's design. It's also possible to overdo it by using too many visual signifiers that confuse the user. In this post, I'll show you some examples of how to use non-color elements to indicate the presence of links.

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, such as:

  1. body text links,
  2. headline and subtitle links,
  3. menu links,
  4. buttons,
  5. image links,
  6. video links,
  7. audio links,
  8. etc.

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

What WCAG 2.0 says

According to WebAIM's guidelines about links and hypertext, 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 link styling you can check out by disabling all styles using the Web Developer Toolbar.

Example: Chrome's default link styling

For instance, this is how the homepage of the Mozilla Developer Network 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 internet users can easily recognize them. It's not a coincidence that the Nielsen-Norman Group also considers blue the safest link color choice in its Beyond Blue Links: Making Clickable Elements Recognizable article.

Non-color designators

WebAIM doesn't recommend removing the underline with CSS, as "users are accustomed to see links underlined". Sadly, many of the biggest websites don't follow this principle 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.

1. Border-bottom

For instance, Bloomberg uses the border-bottom 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 in the usual way.

2. Reverse underline

The Verge uses a different approach to body text link underlines. The underline is present by default, however it gets removed when the user hovers the link. At the same time when the underline disappears, the color also changes subtlely, 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 it still follows the accessibility principle of using non-color designators for links.

3. Icons

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

WebAIM chose an all-inclusive solution for link visibility. Besides the underline, they also add a small icon after each external link. So, the icon doesn't only serve as an extra visual signifier but also clearly distinguishes external and internal links.

WebAIM external link icon

You don't necessarily need to create a link icon by yourself. For instance, Font Awesome has an external link icon you can quickly add to your links.

Font Awesome external links

4. Link text

As screen readers notify users when they come across a link, it's not recommended to use phrases such as "link to" or "follow this link" as link text. Instead, you should provide link texts that describe the main content of the link. It makes it easier for users to decide if they want to click the link, which is especially important for users with 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).

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

Take 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 instead of the action verb (i.e. "Find out more").

The controversial role of 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 somewhere around the link when users hover it.

For instance, take the following line of code:

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

It's displayed like this in the browser: 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. 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 and keyboard-only users. Besides, it disappears after around five seconds in some user agents, which doesn't leave enough time to read it.

On the whole, WCAG 2.0 doesn't advise against the title attribute but recommends careful usage. One thing is sure, never use title for important information that is not available in other forms, 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: :hover, :focus, :active, :visited, and :link.

It's an open question whether it's 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 and confusion to the user.

I tend to create one style for the default link state, a second one for the :hover, :active, and :focus states, and sometimes a third one for :visited links. However, I still can't tell if this is the best solution for accessibility. If you are interested in the topic here's an interesting StackOverflow UX discussion on whether the styling of the :focus and :hover states 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.