Links and buttons are one of the main basic elements that you’ll find on any website. Yet, a lot of them are not as accessible as we would like. And we’re bound to make mistakes as developers, if we don't know how they're understood by assistive technologies.

In this short article I'll focus on screen readers and voice recognition and how they deal with links and buttons. I'll not cover every possible problem that could happen. I'm going to reserve that for a different article which I'll publish soon.

Before we continue, I want to avoid any confusion upfront. When we’re talking about links or buttons, I assume that they're using the proper semantic element, a <a> and <button>.

Using a different HTML element — like a <div> which looks like a link or a button — might not be set up right. And this could cause other problems for assistive technologies. If you want to know more on this, I've written an article on why we should prefer semantic HTML.

How assistive technologies understand a web page

This is possible through the use of many accessibility API’s. The platform that the browser runs on uses one of those API’s to read the content of a web page.

How this process actually works in the background would be too much for this article. If you want to learn the details I recommend you to read Web Accessibility with Accessibility API. It’s a great article written by Léonie Watson.

The part that’s important for us to know is that those API's expose certain information. This happens for every object in the DOM. This information is crucial for assistive technologies to understand what each object means.

There are two pieces of information I want to focus on, and those are the role and the name. The role of the DOM object exposes its purpose. It could be a link, a button or something else like an image. The name of the DOM object gives its identity. It’s also referred as the Accessible Name.

So, let’s use the example above to quickly recap what we’ve learned.

• The <main> element will have the role of “main”. The name is empty because we didn’t supply one.
• Each <p> element will have the role of “paragraph”. Again the name is empty since we didn’t supply one.
• Every <a> element will have the role of “link”. The name will be “Read more”. This happens because the name — or Accessible Name — is determined from a list of possible options. And in this case it was the value inside the <a> element that’s used for the Accessible Name.

I’ve picked this example on purpose because it’s quite common to see a list of cards. Each card having a title, some text and at the bottom a “Read more” link.

So, let’s see which problems could happen for screen readers & voice recognition if we leave the example above untouched.

Potential problems for screen readers & voice recognition

When a sighted user sees a “Read more” link that’s near other elements, they’re able to group them together. The context behind the “Read more” link is then related to the text and the title. It becomes clear what to expect when they press the link. This happens because of the Law of Proximity and/or the Law of Common Region, depending on how the elements are visually styled.

Yet, people who rely on screen readers are usually not able to scan the page, and group elements based on visual proximity. So, in this case the “Read more” link doesn’t have any meaning to them.

For people who depend on voice recognition, might be able to group elements together. But, they’ll have a different problem. To interact with elements they say “Click” — I’m using Voice Control on MacOS — followed by the Accessible Name of the link. This will then press the element that matches the Accessible Name.

So, in our first example it would be “Click, Read more”. But, this will number each “Read more” link. Because the voice recognition software doesn’t understand which link they meant.

Both cases lead up to a poor user experience and could end up in frustration. How could we solve this?

The solution (well, one of many)

Well, there are a couple options available to us. But, let’s focus on one solution for now to keep this article brief. I’ll write an in-depth article on a lot more problems/situations and solutions soon.

If we remove the “Read more” link, we could solve both problems. But, what becomes our link then? Well, the entire card could turn into our link. Then give the <a> either an aria-label, matching the value of our title. Or use an aria-labelledby, which then refers to our <div class="title">. Let’s check it out!

When a screen reader user tabs through the links, or use a shortcut to get a list of links. They’ll hear each link announced with the name of the title instead of “Read more”.

The problem with voice recognition is also solved. Because it’s now possible to use the command “Click” followed by the name of the title.

If you’ve liked this piece of content and you want to get regular updates on other things I write about then follow me on Twitter. And if you have any comments or questions then don’t hesitate to DM me!

Conclusion

• Assistive technologies understand the content of a web page through the platform’s accessibility API.
• Links and buttons should be clear on their own, and not depend on their surrounding context to make sense.
• Voice recognition software have shortcuts to interact with elements
• Command “Click” with the name of the label. The label name needs to match the Accessible Name