The Inaccessible Anchor Element

Recently I came across a navigation component in a project that allowed users to move forward and backward through a process. Since the interactive elements lacked focus styles, one of the first things we did was introduce them. However, after adding :focus-visible styles, the backward link wasn’t receiving any styling. In fact, it wasn’t even focusable. So, I inspected the corresponding component and found this (simplified) code:

<a>Backwards</a>

<script>
  const backwardsLink = document.querySelector('a');
  backwardsLink.addEventListener('click', navigateBack());
</script>

Unfortunately, this kind of programmatic navigation is far too common in web applications. I think one reason for this lies in the possibilities which for example single page application routers provide. Not that they are promoting such patterns, but they expose powerful navigation APIs which, when not used mindfully, can easily end up with inaccessible navigational elements.

This made me think: what is the bare minimum for an anchor element to be accessible? To answer this, let’s define the most common types of links.

Types of Links

When thinking about navigation on the web, links generally fall into the following categories:

• Links to another page (internal or external),
• Links to another section on the same page,
• Links triggering actions, such as sending an email or calling someone or even
• Links to downloadable content.

Here’s how each use case is typically implemented:

<!-- Linking to another page on the same website -->
<a href="/">Homepage</a>

<!-- Linking to another website -->
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a">
  The anchor element on mdn web docs
</a>

<!-- Linking to another section on the same page -->
<a href="#types-of-links">Types of Links</a>
<!-- with the id defined somewhere else on the page -->
<h2 id="types-of-links">Types of Links</h2>

<!-- Linking to actions like ...-->
<!-- ... opening a mail program and prefill the recipients mail address -->
<a href="mailto:mail@someone.com">mail@someone.com</a>
<!-- ... directly calling someone -->
<a href="tel:0123456789">0123 / 456 789</a>

<!-- Linking to content which will be downloaded -->
<a download href="/favicon.png">Download favicon</a>

Rendered output of each of the links:

What Makes an Anchor Element (Technically) Accessible

If you navigate through the links above with the Tab key, you’ll notice that each link is receiving focus and has a focus indicator. The common factor among all these links is the href attribute. And the href attribute is the key to making an anchor element technically keyboard accessible. I say technically because accessibility involves more than just focusability. For example this snippet:

<a href="#" onmouseover="dropdownmenu()">Navigation</a>

is not an accessible way for implementing a navigation (example borrowed from Links and Hypertext on WebAIM) because it still relies on mouse interaction.

Or running JavaScript like this:

<a href="javascript:alert('Hello, world!')">Click me</a>

is also a misuse of the anchor element, as it is well documented on the MDN web docs.

And opening links in new windows for example is a whole other story, which you can read in depth about in Adrian Roselli’s article about link targets and WCAG success criterion 3.2.5.

The Importance of an Accessible Name

Another key accessibility factor is the link’s accessible name–a label that clearly describes its purpose and destination. Generic labels like “more info” or “click here” are problematic because screen reader users navigating via links will hear an ambiguous list with no context.

Best Practices for Accessible Links

Since I wanted to be brief with this article, here are the three basic requirements for accessible links:

1. Use a valid href with a real destination.
2. Provide a meaningful accessible name that unambiguously describes the link’s purpose.
3. Ensure links have visible focus indicators.