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.

Software Documentation Is an Essential Part Of Accessibility

We mostly discuss accessibility as a way to enable people with disabilities to use a tool (website, application, etc.) with as little information loss as possible. However, the accessibility needs of users who don’t have any disabilities but experience other kinds of hardships are less widely discussed.

The lack of knowledge on a given subject is such a hardship. Therefore, providing quality technical documentation to users is an essential part of accessibility. In case of open-source tools, this is probably even more important. Here, users don’t simply want to use the tool but many of them would also contribute to the code.

If you have ever had to use poorly documented software you know what I am talking about. Boring, badly structured, and user-hostile documentation can make people give up on a tool, just like an overly complicated purchasing process can result in shopping cart abandonment on eCommerce websites.

Two types of technical documentation

Essentially, there are two types of technical documentation (however, you might find more, for instance this article mentions eight types):

  1. documentation created for end-users
  2. documentation created for developers

End-user documentation

Companies tend to focus more on end-user documentation; you can find nice and user-friendly examples of this kind of docs. However, even the best designed end-user docs tend to lack crucial accessibility features (e.g. sufficient color contrast, or captioning for instructional videos).

For instance, have a look at Salesforce’s Learning Centre. Overall, they did a great job with the docs. The information is well-structured and logical, and the docs don’t use too much technical jargon.

On the other hand, you will find that some of the necessary accessibility features are lacking. For example, links are distinguished only by color instead of providing a non-color designator such as an underline.

Salesforce Learning Centre - Documentation Accessibility
Salesforce Learning Centre

Developer documentation

Technical documentations created for developers had been in a poor state for many years. They didn’t simply lack accessibility features but also used unstructured text blocks, unreadable fonts, and small line height, lacked table of contents, and were visually unappealing on the whole.

The rise of video tutorials made the scene of developer docs much better. At about the same time, well-designed documentations began to appear.

The first developer documentation I really liked was the Zurb Foundation Docs. It has improved a lot since I first saw it, but even the earlier versions were designed, written, and structured in a way that made me want to learn.

Foundation Docs - Documentation Accessibility
Foundation for Sites Docs

Atlassian’s Git Tutorials constitute another good example for user-friendly developer documentation. They are just as well-structured as the Foundation Docs but also come with great explanatory illustrations (in SVG!) and a downloadable cheat sheet.

Atlassian Git Docs - Documentation Accessibility

While both Foundation Docs and Git Tutorials present the information in a way that is accessible to users without any knowledge on the subject, you will find some accessibility problems in both, that may hinder users with disabilities (for instance, color contrast problems).

Two levels of documentation accessibility

Basically, documentation accessibility has two levels:

  1. The docs need to be accessible for users without sufficient knowledge of the tool.
  2. The docs need to be accessible for users who may have different disabilities.

The two levels can also intersect, as there can be users who are affected by both problems (i.e. don’t have the sufficient knowledge plus have a disability).

The three examples I mentioned in this article (Salesforce, Foundation, Atlassian) handle the first level of documentation accessibility really well, as they:

  • don’t use technical jargon, or if they do they give the necessary explanation
  • provide menus / widgets / table of contents to ease navigation
  • structure pages (careful typography, enough white space, vertical rhythm, etc.)
  • provide illustrations or instructional videos
  • provide examples of usage, demos, or code snippets

They also partially implement the second level of accessibility, however you’ll find issues here and there with things such as color contrast, link visibility, video captioning, etc.

Can documentation be perfectly accessible?

I don’t know if perfectly accessible docs exist or not. If they do they should implement both levels of documentation accessibility. It’s certainly not something easy to accomplish, as there are so many things to pay attention to.

However, documentation accessibility is still an important part of accessibility. First, because we shouldn’t exlude users with disabilities from adopting new technologies, but also because it greatly impacts how many people are willing to go the extra mile to pick up a new tool.