Improving hyperlink accessibility and readability

This topic is split into two parts. This article is part one and will step you through a project exploring how accessible hyperlinks really are, as well as how to design accessible and consistent hyperlinks that can be used in any Design System. Part two is coming soon and will feature a case study that highlights how the Queensland Government website enhanced hyperlink design for better accessibility.

Hyperlinks, known more simply as links, are an essential part of web content. They allow you to navigate websites efficiently by connecting pages and directing you to content. The most recognisable form of the link is the underlined text link, but links also include components such as buttons, menu/ navigational items, accordion headers, tabs.

Designing links that are both readable and accessible can be challenging. People with different levels of reading skills and abilities may struggle to read and comprehend underlined link text, and those with visual or motor impairments may encounter difficulties interacting with links. As a designer, it's crucial to ensure that links are designed with readability and accessibility in mind.

In the paragraphs that will follow I will walk you through a project that I ran and lead, in which I explored how to improve on the design of the link for best accessibility and readability. The outcome is a set of design guidelines and design principles which can be applied to any Design System, and when followed, ensures consistency, optimal accessibility, and readability for all link components across their various states (default, hover, focus, active, visited).

The question that started this

This project started after a single inquisitive observation: if underlining text is generally discouraged due to its negative impact on readability, then why are links typically underlined? (See: UK Gov accessibility blog, W3C, University of Hamburg on UX ideas)

The reason for underlining links dates to the early days of the internet, at this time browsers had limited options so the simplest way to show that a link was different to plain text was to just underline it. Fast forward 30 odd years and now placing an underline under a link text is a familiar and globally recognisable UI pattern.

Accessibility wise underlining a link is a preferred option for people who are colour blind, visually impaired or are viewing in direct sunlight. And supports WCAC standard 1.4.1 Use of Colour (Level A) which states that colour should not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

After making this observation I realised that we had a predicament. On one hand underlining hyperlinks is recommended as it is a familiar UI pattern that meets accessibility requirements for people who are colour blind or are visually impaired. But on the other hand, underlines cause problems in reading.

How underlining text affects readability

I dug a little deeper to better understand why underlined text creates a problem in reading. Some of the reasons are:

• The default HTML underlines generally overlaps letters with descenders (tails) these letters are j, p, g, q, y. This overlap makes it harder for some readers to identify letters and correctly read the word.
• Some readers recognise a word by its shape, and adding an underline to a word with descenders will change the overall shape of the word.
• Overuse of in-text links within paragraphs of content run the risk of becoming a distraction.

To understand more about how the above factors can hinder reading comes down to the science of reading and how people with different levels of literacy read. Skilled readers read selectively skimming and scanning content to pick out crucial points. Less skilled readers may need to decipher a word letter by letter, and are more likely to misrecognise a word, they then try to make sense of sentences with words that don’t really fit together which creates confusion rather than understanding.

Is this problem worth addressing?

Initially, I was unsure if the issue of readability would impact a large enough audience to warrant design changes. So, to gain a better understanding of the problem, I conducted extensive research on the various factors that can affect a person's reading ability, as well as the statistics regarding the number of people who are impacted.

Factors affecting a person's reading ability can be divided into cognitive and physical barriers. Cognitive barriers may arise from cognitive learning disabilities like dyslexia (reading) or dyscalculia (maths) but can also be caused by other factors such as content written at a technical or overly complex level, reading in an unfamiliar language, or encountering typography that is difficult to read. Additionally, cognitive barriers can stem from low-literacy due to not having access to education, as well as experiencing a stroke, and dementia. Physical barriers include viewing content on a low-contrast screen or in direct sunlight, limitations in body motor control, vision impairments and tunnel vision.

My research on affected populations revealed signifigant statistics regarding low levels of literacy and dyslexia. 44% of Australian adults lack the necessary literacy skills for daily living. (Source: Adult Learning Australia and Australian Bureau of Statistics) While the Australian Dyslexia Association estimates that one in every five individuals has dyslexia. (Source: Australian Dyslexia Association)

Given this data, designing for reading accessibility should be the norm rather than an exception.

A gap in the WCAG

So why is there a problem? Shouldn’t everything be fine so long as WCAG standards are met?

This is where things get a little blurry - as comprehensive, and thorough as the WCAG accessibility standards are, it is still a living document, growing and evolving with time. Not all accessibility needs and requirements are currently documented, and specifically, not all cognitive accessibility needs are currently addressed in the existing standards. Meaning that there is currently limited guidance provided by the WCAG for how to support people with dyslexia and lower levels of literacy.

Filling the gap

Now knowing that there is a problem with link accessibility, and that there is currently limited guidance provided by WCAG with regards to accessibility in reading, I developed my own guidelines to ensure success in the improved designs. These guidelines complement existing WCAG accessibility standards and are intended to fill the gap related to reading underlined link text.

To do this I analysed the different ways in which underlined text can cause issues for individuals and employed the "5 whys strategy" to uncover the root causes of each problem. I then rated the importance of each root cause and explored ways to effectively address them. More information on the 5 why’s strategy.

Uncovering the root cause of each problem…

Matrix of all problems defined in the root causes list, rated by importance, why the problem is happening and possible ways to solve

Putting this all together

Now armed with a comprehensive understanding of how underlines function in user interfaces and how people read, I was able to start designing solutions.

I employed the principles of atomic design to develop a base design and set of guidelines for all link states (default, hover, focus, visited, and active) that is consistently applied to all link components such as in-text links, buttons, menu and navigation items, accordions, tabs, and so on.

Base design

So here is the new and improved link design. For accessibility and readability purposes the link will continue to be underlined, but the underline will be moved 5px (0.3em) below the baseline of the text so as not to obstruct the descenders of any characters of a word (such as j, y, g, q, p) and in turn, not cause any problems for reading. This is achieved by using the CSS underline offset property.

Wait does this mean that every links needs to be underlined!?!

Yes and no. These new guidelines advise that for the default state (e.g. not on hover etc) a link component should only be underlined if there is no other recognisable visual indicator or UI pattern that makes it clear that the component is a link.

But on the hover state ALL link components will have an underline.

Here are some scenarios for when and when not to underline a link component in the default state:

	In-text hyperlinks	In-text hyperlinks must always be underlined in the default state
	Primary and secondary buttons	Underline is not required for primary and secondary buttons as there are other UI patterns used in these components.
	Tertiary buttons	Underline is required in the default state as tertiary buttons look too similar to standard text.
	Links in multi-action cards	Links in multi-action cards require underline in the default state, as it may not be clear to visitors which parts of the card are links and which are not.
	Navigation links	Navigation links do not require an underline at default state as this is a familiar UI pattern.

The designs across states

Default state

If a link is deemed to require an underline at the default state, the underline will have a weight of 0.5px (0.031rem). The colour of the underline will also be lighter tint of the link text colour (minimum contrast 4.5:1).

The purpose of using a thin underline weight with a light colour is to present the underline under the hyperlink in a more ‘muted’ way. This ensures that the underline is still noticeable but does not distract from the rest of the content.

Hover state

All link components MUST have an underline on the hover state.

In the hover state, the weight of the underline will increase to 2px (0.13rem), and the tint of the underline will also increase to be the same tint as the link text colour.

Increasing the underline weight and tint on hover ensures that the transition between default state to the hover state (and back) is based on movement and not on colour change. Basing the transition between states on movement rather than colour ensures that people who are colour blind or are visually impaired can see the change.

Visited state

In the visited state, the link component will match the characteristics for default, hover, focus and active. For in-text links the link will be a different colour, indicating that this link has been previously visited.

Focus and active states

For accessibility purposes, it is strongly recommended that all link components have a focus state, such as a strong box around the link or a high contrast background.

Creating more complex link components

These rules and designs form the base of all link components; in atomic design this is known as an atom. To create more complex components such as buttons, accordions, tabs, cards, will require adding on top of these designs.

Progressive enhancement

The concept of progressive enhancement is evident in the weight of the underline in the default state.

In CSS, pixel size can vary depending on the resolution of the screen. On high-resolution devices, a single CSS pixel may span across two device pixels, so a half CSS pixel will cover one device pixel. Conversely, on lower resolution devices, a half pixel will round up to the nearest whole number. By utilizing a 0.5px width, we can maintain compliance with accessibility standards 1.4.1 Use of Color (A) and 1.4.3 Contrast (Minimum) (AA), while also achieving a sleek and aesthetically pleasing design.

Presenting this work

I delivered multiple presentations on this research and designs, to audiences from various departments within the Queensland Government. Typically, between 30-50 individuals were present at each session.

Interested in learning more?

The improved hyperlink designs are currently being rolled out on the Queensland Government website. These designs and guidelines are also currently being incorporated into the QLD Health Design System.

If you have any questions or would like to discuss this project further, please contact me.