Website Accessibility: What is Aria and Why Does it Matter? A Quick Overview

I was once in your shoes, friend – I was a little confused (puzzled, flabbergasted) when I heard the term ARIA. I didn’t know how ARIA worked. So, if you are like me back then, you might be uncomfortable talking about the subject.

If you’re confused by it, don’t worry—you’ve come to the right place! I’ll break down what it is and how you can use it to make your code work for people with disabilities who use assistive technology.

Ultimately, I would like to communicate the subject to you in a way that is accessible and informative. In other words, I don’t want to make your eyes glaze over with boring jargon.

What is ARIA?

ARIA is an acronym for Accessible Rich Internet Applications, a set of attributes you can add to HTML elements. ARIA attributes can be Roles or States and Properties. These attributes define making web content and applications accessible to users with disabilities.

People with special needs use assistive technologies(AT). So when HTML doesn’t get the job done, ARIA is a godsend to help users navigate your website using screen readers like JAWS, NVDA, Windows Eyes, etc.

What is an ARIA role?

Roles define what an element is or does. The default role often provided by HTML elements is sufficient for most sites.

Most HTML elements have a default role that is presented to assistive technologies. For example, a button has a default “button” role, and a form has a default role of “form.” You can override this, though, for any elements using ARIA.

Adding ARIA to HTML can make your page more accessible to screen readers. But, it won’t change how the page looks or how other browsers read the content to users. Still, it will give the reader extra information about the content they are currently reading.

For example, you can add extra descriptive layers for screen readers using aria attributes like aria-role, aria-label, etc. Still, for functionality, you will need to use JavaScript to make the element behave in a certain way.

But suppose you’re building an application or adding complex functionality using nonnative HTML elements. In that case, you need to make sure you add the right ARIA attributes to get the job done. The best part is that it’s easy to implement, but there is a catch!

This means that if you use ARIA, it will not add new functionality to the page or element you are using it on. So if you use a custom HTML element that you created, you need to add the functionality yourself. That’s because that element is like wearing a costume and pretending to be something else.

Now, please entertain my shenanigans for a second. Let’s take a chihuahua, for example. You can dress it up using an aria-role=” lion” to make it look like a Lion, but it’s still a little doggie. So, of course, it’ll bark and eat doggie food because it is a dog.

But it won’t roar, no matter how much you wish it would. So, to make it roar – you’ll have to modify the cute little thing genetically – sorry for putting such a horrible visual in your psyche.

The same happens when you use an image as a button since that counts as a custom HTML element. By adding an aria-role=” button,” you can fool screen readers into thinking it is a button. But still, it will lack all the functionality a button has, like onclick events and other properties, which means you will need to add those using JavaScript.

Best practices suggest using native HTML elements when building websites rather than making-up new ones, like when you use images as buttons. Using native HTML elements for the job such as a real button is the best choice.

It will provide your website or application with broad support for screen readers from the very beginning. If at all, you will only need to add some minor aria attributes to enhance the experience.

ARIA attributes are divided into roles and states & properties. An ARIA role does not change for an element once it is set. But states and properties can change—sometimes true or false, and other values depending on the ones you use.

What is an aria-label?

If you’ve got your eyes glazing over at this point, it’s totally cool. But, of course, you’re now an ARIA connoisseur, so you may be asking yourself, “What is aria-label?”.

An aria-label is a text string that identifies the purpose of an element. The aria-label attribute defines a string that labels the current element.

The text in an HTML element (by default) is usually used as an accessibility label. But when the element has an aria-label, the accessible name becomes the string inside it.

If you are unaware, a string is a text inside single or double-quotes. Aria-label is used by adding it to specific HTML elements and putting its value inside the quotations.

<button class=”close-button” aria-label=”close”>X</button>

A screen-reader would read this button as “close, button.” Without the aria-label, it would read “X, button.” which can confuse blind users trying to make sense of your website, what the heck is an x button? exactly!

Do aria-labels have to be unique?

Each standard HTML form control and ARIA widget role must have a unique label on the page. If a label in the aria-label attribute isn’t unique, you risk getting the wrong string back — and then end up with coding errors on your hands.
Where can I use the aria-label?

We should use the aria-label attribute mainly in interactive elements, landmark elements, and element tags with an explicit widget role. These tags can also be used in the iframe and img elements.

• Interactive elements: input, select, button, textarea, audio, and video (when the controls attribute is present), .
• Implicit landmark elements: header, footer, nav, main, aside, section, and form.
• Explicit landmark elements: elements containing role= “navigation.”
• Widget role elements: element containing role=”dialog” or role=”tooltip”

Ultimately, you’ll want to use the aria-label in locations to provide an element with a text alternative. If you didn’t, the element wouldn’t have any text for a screen reader to articulate to the end-user.

Any other elements like div, span, p, blockquote, or strong generally won’t work across all browser or assistive technology combinations.

What are the most commonly used ARIA roles, states, and properties?

The following are the ones I mostly use. Still, you should take a look at the rest of the aria attributes, so you can get familiar with them.

• aria-activedescendant: Identifies the active descendant of the current composite widget. Use with autofill search suggestions.
• aria-autocomplete: Demonstrates if user input completion has been provided. Use with autofill search suggestions.
• aria-checked (state): Demonstrates the current state of checkboxes, radio buttons, and other widgets. The state can be set to a true, false, or mixed state.
• aria-controls: Identifies the element (or elements) whose contents or presence are controlled by the element on which this attribute is set.
• aria-describedby: Describes the object identified by the element or elements.
• aria-disabled (state): Demonstrates the element is perceivable but disabled, so it is not editable or otherwise operable.
• aria-expanded (state): Indicates whether the element or grouping element it controls is currently expanded or collapsed.
• aria-hidden (state): Indicates that the element and its descendants are invisible or not perceivable by any users.
• aria-invalid (state): Indicates the entered value does not conform to the format expected by the application.
• aria-label: Defines a string value that labels an interactive element.
• aria-labelledby: Identifies the element (or elements) that labels the element it is applied to.
• aria-live: Demonstrates that an element is dynamic, changing, and updated. Also describes the types of updates the user can expect from the live region.
• aria-owns: Identifies an element or elements to define the visual, functional, or contextual parent/child relationship between DOM elements when the DOM hierarchy cannot represent the relationship.
• aria-pressed (state): Demonstrates the current “pressed” state of toggle buttons. See related aria-checked and aria-selected.
• aria-required: Demonstrates the user input is required on the element before a form may be submitted.
• aria-selected (state): Demonstrates the current “selected” state of various widgets.

Conclusion

If you’ve stuck with me this far, give yourself a big pat on the back. You did great learning about ARIA and aria-labels.

We learned the importance of ARIA in helping people with disabilities get around your site, especially people with vision problems. Aria-labels allow strings to communicate with screen readers to describe the functions on your site more accurately.

I’m confident you will be able to use aria-labels as well as roles, properties, and states in your HTML.

Did you find this information helpful? Are you going to use ARIA on your website? Please let me know your thoughts in the comments below. Also, please give this article a thumbs up to support more content like this.

If you want more information on web accessibility, make sure you check out my YouTube channel. Also, make sure to follow me on Instagram for shorter and more visual content.