What I Learned at Work this Week: aria-label and aria-labelledby
This week, I received a ticket from a client that is very focused on accessibility. They asked that we change an aria-label in one of our elements to an aria-labelledby and I had some trouble with the request because…I had never used either one of those attributes before. It was a thrill to address the request and see how my code affected the text on our screen reader and it helped me better understand the challenges of web browsing for users who are visually impaired. As web developers, we all strive to create the most natural and seamless experience possible, so I’m researching aria-label and aria-labelledby this week to solidify my knowledge of these accessibility tools.
Screen Readers
Before this week, I had never used a screen reader before and didn’t even know that my computer had that functionality built into its operating system. If you’d like to get an idea of what it’s like to test some of the code I’ll show in this post or just generally get an idea of the screen reader experience, Codecademy has a very helpful article about getting set up. I’ll be using the macOS screen reader, which can be activated through System Preferences => Accessibility => VoiceOver.
Screen readers convert digital text into speech, so when we’re online, that means working with html. To test and illustrate the my work for this blog, I created a simple html webpage:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content=”width=device-width, initial-scale=1.0">
<title>Mike’s Blog</title>
</head>
<body>
<h1>I hope you like my page!</h1>
<div>Button Options</div>
<br>
<button>Continue</button>
<button>
<img
width=20
height=20
src="https://us.123rf.com/450wm/martialred/martialred1507/
martialred150700939/42621315-stock-vector-thumbs-up-like-line-
art-icon-for-apps-and-websites.jpg?ver=6"
>
</button>
<body>
</html>If you paste this into your IDE of choice and then open the webpage, you’ll see a very simple webpage:
But if you turn on your screen reader and try to interact with the page, it’ll be much more difficult. You’ll probably notice, as I did, that there is actually no way to read the “I hope you like my page!” header. Keep in mind that a user who is visually impaired is likely using their keyboard exclusively for navigation. They are unaware that this element exists and they wouldn’t know how to access it even if they did. So the first thing I have to add is an attribute called tabindex. This allows me to curate an order of navigation for my users who may be using tab to traverse my site. Since this is my header, I’ll set the tabindex at 0:
<h1 tabindex=0>I hope you like my page!</h1>By adding this attribute, I’m now able to focus on the h1 element by clicking or tabbing onto it. If I’m using a screen reader, it’ll say something along the lines of “Heading level one. I hope you like my page!” Much more helpful!
We can also see that our users may choose to “continue” (which currently leads nowhere) or “like” our content. We could argue that the “continue” button is self-explanatory, but the “like” button is just a royalty-free image that I found on 123rf.com. If we focus on it with a screen reader at this point, it won’t be able to describe it.
But we still don’t have to get into anything fancy. By adding an alt attribute, we can describe the image:
<button>
<img
width=20
height=20
alt="thumbs up"
src="https://us.123rf.com/450wm/martialred/martialred1507/
martialred150700939/42621315-stock-vector-thumbs-up-like-
line-art-icon-for-apps-and-websites.jpg?ver=6"
>
</button>That’s a big improvement over where we started, but there’s still opportunity for confusion. There are circumstances where I’d like to be more descriptive, which is where aria-label comes in.
aria-label
ARIA stands for Accessible Rich Internet Applications, so it’s no surprise that aria-label is used to label an element for accessibility. The attribute is assigned a string that is not displayed on the page, but will be read by a screen reader. Aria-label overrides other labelling attributes, so we won’t read the alt description, nor would we hear the button’s inner text (if it had any). My alt attribute describes an image, but my aria-label can explain what it does:
<button>
<img
width=20
height=20
aria-label="press ENTER to like the page"
src="https://us.123rf.com/450wm/martialred/martialred1507/
martialred150700939/42621315-stock-vector-thumbs-up-like-
line-art-icon-for-apps-and-websites.jpg?ver=6"
>
</button>Now let’s revisit our page again:
Aria-labelledby
The aria-label attribute seems great, so why was I asked to use aria-labelledby instead? Google’s Developers page provides a thorough description of the differences between the two, but if you’re looking for a simple distinction: aria-labelledby references another element for a description. That element can have visible and invisible children, all of which will be read by the screen reader if we’re using aria-labelledby.
To make good use of aria-labelledby, I wrapped my header in a div and added another element with the label text I had previously used for my like button. I want to remind my users how much I want them to like my page when they’re considering using the button:
<div id="button-label">
<h1 tabindex=0>I hope you like my page!</h1>
<div style="color:white">press Enter to like my page</div>
</div>
<div>Button Options</div>
<br>
<button aria-labelledby="buttons">Continue</button>
<button>
<img
width=20
height=20
alt="thumbs up"
aria-labelledby="button-label"
src=”https://us.123rf.com/450wm/martialred/martialred1507/
martialred150700939/42621315-stock-vector-thumbs-up-like-
line-art-icon-for-apps-and-websites.jpg?ver=6"
>
</button>To keep things simple, I just changed the text to white to hide my element, but of course there are much better methods if you’re actually implementing this technique. But now if I access the “like” element using a screen reader, it’s even more robust:
Accessibility
If you had the patience to follow along at home, I expect that the most valuable lesson learned from this blog is how challenging it is to navigate a computer or webpage using a screen reader, even on professionally and meticulously audited platforms. Examining and enhancing these tools is critical for all web developers and I’m excited to see how they will evolve in the future. Never forget that the internet should be accessible to all, regardless of their income, location, or physical ability.