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 theroleof “main”. Thenameis empty because we didn’t supply one. - Each
<p>element will have theroleof “paragraph”. Again thenameis empty since we didn’t supply one. - Every
<a>element will have theroleof “link”. Thenamewill be “Read more”. This happens because thename— 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
Top comments (4)
Great article, Just a heads up I think you may have mad a slight mistake with putting the link to your updated codepen within a codeblock.
FYI You can include codepens directly within your article using liquid tags if you find that easier!
Other than that really well explained and nice example of a common accessibility issue and solution! ❤🦄
Thanks for showing me how to include a codepen. I went with the iframe option first, because that was the only option that worked within Obsidian, where I write my articles. Guess I have something to check out this weekend how to fix this for Obsidian, NextJS/MDX (my website) and Dev.to 😄
Yes, fiddles and stuff provide a nice warm welcome to the wonderful world of cross post hell! 🤣
Thanks @inhuofficial for the compliments and of course for pointing out the mistake! I’ll correct it in a bit!