The content you can’t see: when and how to use ARIA labels
Photo Description: Close-up of hands reading a Braille book on a wooden table. Wearing a light ribbed shirt, fingers gently glide over raised dots.
Whether you’re a UX designer, content writer, or developer, knowing how and when to use ARIA labels is critical to building a more accessible product. It’s important to work with your teammates to communicate when an ARIA label should be used and what it should say to ensure it’s implemented correctly. When the whole team is aware of and involved with incorporating ARIA labels when necessary, you’ll be able to level up the accessibility of your work in fantastic ways.
Imagine you’re a sighted user and you saw a button on the screen that read “button.” No other context. You would have no idea what that button does. For all you know, it could delete something you need. That would be infuriating, wouldn’t it?
That’s exactly what happens when assistive technology users come across an icon button that has no visible label and no ARIA label. A screen reader, for example, just reads out “button.” No other context. If you have a group of icon buttons without ARIA labels, all users will get from a screen reader is “button, button, button” as they tab through. This essentially renders the user interface useless to assistive technology users.
So how do ARIA labels help, and how can you write ARIA labels to make your UX accessible for assistive technology users?
Photo Description: Close-up of eyeglasses on a desk focusing on a computer screen displaying software and code. The lenses provide clarity, with blurred surroundings.
What are ARIA labels?
Assistive technologies read the code that builds the user interface to present to the user, but these technologies can’t “see” the interface to understand it. So, when you use images to convey meaning or relate interactions to one another based on position, the assistive technology can’t automatically understand this, and therefore doesn’t present this information to the user.
That’s where ARIA, or Accessible Rich Internet Applications, attributes come into play. These are used in code to help assistive technologies, like screen readers and Braille displays, present a user interface to a user in a way they can interpret and interact with. They can relate elements to each other, convey the status of an element, and convey information that’s only available visually, allowing assistive technologies to process that information and present it to users.
ARIA labels are code elements written as aria-label=“ followed by the words you want an assistive technology to convey to a user. These inform a user of the purpose of an interactive element, like a button or input, when there isn’t a plain text label or when the plain text label isn’t enough to convey that purpose.
Writing ARIA labels
The main things you need to consider when writing ARIA labels are the amount of context the user needs to understand an element’s function and how much of that context is only available visually.
For example, consider a library of files on a database. You have a lot of files on the screen, and each one has an action menu. If you’re a sighted user and you’re using a mouse, you can see that the action menu is on a tile or line item that is connected to a particular file. When you hover your mouse over the three dots, a tooltip appears that says “Actions.” Imagine if the creators of the database just used “Actions” as the ARIA label and didn’t otherwise give users context. All assistive technology users would get is “Actions,” and they wouldn’t know what file those actions would affect.
If you’re writing an ARIA label, you need to take that visual context into consideration. Of course, just like with writing visible labels, there’s no one right way to write them, but there are a lot of wrong ways. For the “Actions” scenario, some good ways to offer context through ARIA labels could be:
Actions for <FileName>
<FileName> actions
Open menu for <FileName> actions
Photo Description: Two people collaborating on a laptop, one pointing at code on the screen while the other watches intently.
It’s important to be specific. While there are other ARIA attributes that can relate the “Actions” menu to the file, these are often read by assistive technology later than the accessible label. As we all know as UXers, the faster and more efficiently we can get someone the information they need, the better. So, if we can get them that information right from the beginning, the faster they’ll be able to determine what they need to do and if this element will allow them to do it.
Do’s and don’ts of writing an ARIA label
Do
Keep it short and straightforward just as you would for a visible label.
Only use ARIA labels when there are visible labels if the visible label doesn’t include enough information on its own.
Check with your developers to make sure they’re using ARIA roles and properties to clearly announce the element and its relationship to other elements when possible.
Consider any context that is only offered visually and figure out if that’s best announced in an ARIA label or ARIA description.
Don’t
Repeat a visible label as an ARIA label will cause assistive technology to repeat the label multiple times, confusing a user. Visible labels should be attached to an element using the <label> element with the for attribute or aria-labelledby.
Use the element type in the ARIA label like “button” or “navigation” as screen readers and other assistive technologies already announce these.
Try to convey instructions through an ARIA label. There are ARIA descriptions which are meant for longer instructions or context.
More accessibility starts with you
Photo Description: Three men working on a laptop, one pointing at the screen while another watches. One man in a wheelchair has prosthetic arms.
It may seem like a small step, but incorporating ARIA labels into your work makes a massive difference in how accessible a product is. Collaboration between UX designers, developers, and content strategists helps to ensure that we’re using and writing ARIA labels correctly, especially when you have multiple people considering the problems that ARIA labels can solve. Now, you’re one step closer to making your work more accessible, so go out there and help your users more than ever before.
Meet the Author | Jessica Bjoeredahl
UX Writer and Content Strategist
Jessica graduated from Kennesaw State University in 2015 with a degree in English. Soon after, she broke into the writing field, specifically in the Marketing sector, where she wrote blog posts, product descriptions, and social media posts. When she needed a change, she stumbled into a UX writing position and immediately fell in love with the field. In the 6 years since, she’s been dedicated to creating inclusive, accessible content to reach users where they are and meet their needs. Between professional courses, workshops, and research throughout her career she has learned a lot about terminology, taxonomy, mental models, accessibility, and inclusivity (in UX and beyond). What has she found? The words we use are incredibly impactful, and they’re more than their dictionary definitions. This is why she considers context, user mindset, accessibility, cultural differences, and connotation in every word and guideline she writes.
