Skip to content

Contact sales

By filling out this form and clicking submit, you acknowledge our privacy policy.

How to Make Your Web Links Screen-Reader Friendly

Sep 12, 2020 • 4 Minute Read

Introduction

Links are a ubiquitous part of the web. It's important that they are easy to use for all, including screen-reader users.

In this guide, you will learn about the Web Content Accessibility Guidelines and how to apply them for the purpose of making your websites links user friendly for screen readers. It will also offer specific recommendations for applying three principles for links: they should be perceivable, understandable, and operable.

Make Your Links Perceivable

Screen readers provide user feedback in two main ways: beeps and voice output. Beeps are reserved for specific events, such as entering text input mode, and not typically used when navigating through the links of a webpage. As such, text is the primary way a screen reader user gets feedback on what page they are on and where a link may take them.

Sometimes you may want to display your link as an icon. To make this screen-reader navigable, you must add some inner text inside the anchor tag.

      <a href="/">
  <i class="fas fa-home" aria-hidden="true"></i>
  <span class="sr-only">Home</span>
</a>
    

When a screen reader user focuses on the link, the screen reader will announce link home. This informs the user they have encountered a link element name is "home"; this is enough information to infer where activating the link will take the user.

Make Your Links Understandable

It is also important that you give useful labels to your links and not use naked links. When a screen reader encounters a link, it will read out the link text to the user; if the link text is a URL, i.e., a naked link, the user will hear a stream of incomprehensible symbols.

The following is an example of a naked link.

      <a href="https://my-blog.com/top-articles">https://my-blog.com/top-articles</a>
    

A friendly version of the above link:

      <a href="https://my-blog.com/top-articles">top articles</a>
    

Link text should tell users where they will be taken if they activate the link. "Click here" and "this link" can be improved. "Top articles" is a better example since the user can infer what content lies behind the link.

Make Your Links Keyboard Operable

On a large website, there can be over 100 interactable elements on the page. One way a user can make sense of a website is to check the navigation menu to see what information they can find. While a sighted user can rely on visual elements such as margins, shadows, and colors to find this navigation menu, a screen reader user will rely on landmarks to perform the same operations.

Without landmarks, a user will be forced to press tab dozens of times to cycle through every single interactable element on the page, including form fields, search boxes, links, menus, etc. This is undeniably a terrible user experience. The good news is that creating navigation landmarks is simple using the <nav /> semantic HTML tag. This is demonstrated below:

      <nav>
  <ul>
    <li>
      <a href="/top-articles">Top Articles</a>
    </li>
    <li>
      <a href="/hire-me">Hire Me</a>
    </li>
    <li>
      <a href="/support">Support the Blog</a>
    </li>
    <li>
  </ul>
</nav>
    

A screen reader will identify all the landmarks on the page. A user can cycle through all the landmarks and easily find this navigation menu in a few keystrokes. Also note that the links are wrapped in <ul /> and <li /> HTML tags. These help screen-reader users understand how many items are in the list, navigate back and forward in the list, and skip to the end of the menu easily.

Conclusion

This guide has provided recommendations for how to make your web links keyboard operable, understandable, and perceivable for screen reader users.

Benney Au

Benney A.

Benney is a senior software engineer and architect. Benney started believing he would be an economist and even got the degrees to prove it. It was only after discovering he could teach himself programming by reading documentation did he became consumed by it. These days his colleagues can’t tell if he’s a react developer, .net developer, data engineer or risk analyst.

More about this author