Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Lessons in Accessibility: Aria Attributes

Written by: Michael Vano

As the web is becoming more and more complex, it’s very important to make it as accessible as possible. Aria-attributes are little code helpers to make a website more accessible for everyone.

They are primarily utilized by screen readers, which will look at these attributes and get a better understanding of what they need to read out to a user.

Now, before continuing on, it is important to remember that making a website accessible does not mean you have to use all these attributes or use as many as possible. Many times, websites aiming to be accessible may keep throwing on these aria attributes when it’s not really needed. We’ll look at some examples later on in this post. Just remember that less is more when it comes to developing an accessible website.

What are they?

Aria attributes primarily exist to help define a state or property of an HTML element, typically an interactive one, or even stating that it isn’t interactive in some cases, like aria-disabled.

We’ll look at some of the more commonly used aria attributes and explain what they’re used for; aria-label, aria-describedby and aria-hidden. There are many attributes available. Here is a link where you can find a list of all available aria attributes.

Remember, you don’t have to use them all.

aria-label

aria-label” is extremely useful as it can give context to an element. Think of a close button. The code could look like this.

<code>
<button> X </button> 
</code>

It shows an “X” and visually, you’d understand it meant to “close something”, but a screen reader would just see “x”, which is just a letter.

This kind of scenario is perfect for the aria-label and what it’s really meant for; giving appropriate context.

<code>
<button aria-label=”Close”> X </button>
</code>

Now the screen reader will read this button as a “Close” button. You can even give a bit more context if you wanted and put “Close dialog” if this was in a modal or “close menu” if it was in a pop-up menu.

Visually, we’d be able to identify what the button will close. But some screen reader users may not be able to visually understand that context, so the aria-label really helps in this kind of situation.

Now if you had a button that has text already describing what it does, you wouldn’t need the aria-label. Have a look at this.

<code>
<button> Reset Form </button> 
</code>

This is perfectly fine. It’s clear, straight to the point and there is no need to add the aria-label. One less thing to worry about. There is enough context in the button to understand what this button is for.

aria-describedby

Aria-describedby, primarily is used for inputs, to add those extra little ‘good to know’ pieces of information. It describes the element in further detail.

Let’s look at this piece of code. It is an input used for a password.

<code>
<label for=”passwordInput”>Password</label>
<input id=”passwordInput” aria-describedby=”passwordRules“ type=”password” />
<div id=”passwordRules”>Password must be longer than 8 characters. </div>
</code>

Notice the value in “aria-describedby” uses the id from the other element as its value; “passwordRules”. It’s referencing the element, similar to how the label is referencing the input.

This tells the screen readers “Hey, I want the text in this element to describe this input”.

So now, when a screen reader lands on this input, it’ll first read out what the element is; a password text field that’s editable and has a label “Password” attached to it. (Note: Various screen readers will read this out differently from each other. This is a generalization and not what is actually read out.)

Because it is being described by some other text as well via “aria-describedby”, the screen reader will then begin to read out the description text being referenced; “Password must be longer than 8 characters”.

Aria-describedby lets the screen reader know what existing text on the page should be used to describe the element.

aria-hidden

Aria-hidden allows us to “hide” elements from a screen reader. A typical use case for this would be using font icons.

<code>
<button>
     <i class="fa fa-home"></i>
</button>
</code>

A font icon library, like Font Awesome, will use Unicode to display icons and the screen reader will make a valiant attempt to read out that Unicode, which can result in unwanted results.

Using aria-hidden will tell the screen reader to “ignore” this element and not to read it out. In place of the icon, we can utilize the aria-label we learned about earlier to give appropriate context.

<code>
<button aria-label=”Home”>
     <i class="fa fa-home" aria-hidden=”true”></i>
</button>
</code>

With this code now, the screen reader will not attempt to read out this element and the button now is labeled via the aria-label.

A more interesting use case for aria-hidden is to use it on elements being referenced within an aria-describedby. Let’s look at the aria-describedby example code again.

<code>
<label for=”passwordInput”>Password</label>
<input id=”passwordInput” aria-describedby=”passwordRules“ type=”password” />
<div id=”passwordRules”>Password must be longer than 8 characters. </div>
</code>

When using a screen reader, a user can navigate through all elements with content using cursor arrows, which will hit every text element. So, with this code as is, if a user is using cursor arrows to navigate, they’ll hit the input, read out the label and all the described by text. Then, if they continue navigating, they’ll encounter the text that was just used to describe the input. This can be annoying and potentially confusing, because they already heard that text. Just imagine going through a door only to enter a room that looks exactly the same as the last room you were in.

To avoid that, we can use aria-hidden to hide these descriptive text elements from the screen reader.

<code>
<label for=”passwordInput”>Password</label>
<input id=”passwordInput” aria-describedby=”passwordRules“ type=”password” />
<div id=”passwordRules” aria-hidden=”true”>Password must be longer than 8 characters. </div>
</code>

This will now hide the description text element “passwordRules” from the screen reader.

But, what’s really nice is that the “passwordRules” element will still be found via aria-describedby. Aria-hidden hides elements from being found through screen reader navigational means, but it doesn’t prevent those same elements from being referenced by other elements.

This is extremely useful so we can help reduce the “noise” and “clutter” that screen readers will have to go through when navigating a page.

Things to Keep in Mind

So hopefully you can start to see how these aria-attributes are helpful in constructing a better user experience for screen reader users.

If you’re not sure what a particular aria-attribute is used for or how to use it, just read up on it. The w3 website’s list of aria attributes gives you tons of information for each attribute.

On top of all that, you can also whip out a screen reader, VoiceOver for Mac, NVDA for Windows and really get an understanding on how these screen readers “interpret” these attributes.

But most importantly, you need to keep in mind that the landscape of web accessibility is still changing. Screen readers are still being refined and conventions for web accessibility are still being created. Not all aria-attributes will work for all screen readers and browsers.

For example, the aria-sort attribute is a great attribute to describe the sorting state of a table column. Unfortunately, at the time of this writing, it doesn’t work nicely with quite a few screen reader and browser combinations. VoiceOver does not recognize it at all.

There are times we have to find work arounds to mimic how these attributes “should” work, which is something we will get into in another blog post.

But most important to remember, is not go crazy with aria-attributes and don’t overload the user with information through descriptions and content. Simplicity is the way to go for any user experience.