Wakefly BlogARIA and Its Role in Web Accessibility

While this article is technical in nature, it’s important to have a general understanding of ARIA and why it may be needed on your site. Not all websites use or need to use its attributes, but ARIA may offer solutions to create an accessible website.

HTML has implicit meaning and is already accessible to people. When implemented as intended, it is accessible for everyone. However, website’s today are built with complex controls that go beyond what regular HTML offers. Unfortunately, this results in a semantic gap between native HTML and custom HTML. To fix this gap, we use ARIA, whose attributes are intended to be used only when a part or function of a site is difficult to use or unclear with a screen reader or assistive technology.

Defined

WAI-ARIA stands for Web Accessibility Initiative - Accessible Rich Internet Applications. That’s a bit of a mouthful. Its sole purpose is to help people with disabilities that use assistive technologies (i.e. - screen readers) to interpret digital content. The end result is making the web accessible to disabled users and ultimately your website accessible to them.

What Is It?

ARIA is a specification defining how to add missing semantics via a set of HTML attributes. The Web Content Accessibility Guidelines (WCAG) determine how conformance of ARIA should be met.

Since it uses a wide-range of attributes based on specific need, it is primarily meant for developer usage. WAI-ARIA Authoring Practices 1.1 is a developer guide with detailed instructions on how to add any missing semantics.

How Does It Work?

As mentioned above, ARIA adds a set of attribute to bridge any semantics gaps. It does so by using roles, states, and properties commonly recognized by assistive technologies. These three subsections can help you to organize solutions.

• Roles - defines element purpose (button, link, textbox, etc.)
  • When applied, is prioritized over implicit HTML roles
• States - define current conditions of element (aria-hidden, aria-invalid, etc.)
• Properties - defines characteristics of element (aria-label, aria-invalid, etc.)

In order to fully understand this, let’s discuss native HTML first.

Native HTML

When you use native HTML, you get a lot of free stuff. As an example, say you have a checkbox asking a user if they would like to subscribe to your newsletter.

<input id="newsletter" type="checkbox" name="subscribe" value="Yes">

<label for="newsletter">Subscribe to Newsletter?</label>

The above checkbox:

• Has a name, “Subscribe to Newsletter?”
• Implicitly has a role with a value of “checkbox”
• Is keyboard focusable (can use TAB key to get to it)
• Responds to keyboard events (SPACE BAR to select or deselect)
• Has an initial state of “checked” equal to “false”

By using a native element, its usage and behavior is easily understood by screen reader and keyboard users. Nothing additionally needs to be added to make that work.

Custom HTML

Before I get into this custom example, there are several rules of ARIA usage, the first being the most important:

1. Use native elements whenever possible
2. Do not change native semantics, unless you really have to
3. All interactive controls must be usable with the keyboard
4. All interactive elements must have an accessible name

That being said, let’s continue...

Alternatively, say we decide to use a custom element, a <div> element, and present it as a checkbox:

<div id="checkBoxInput">Yes</div>

<div id="checkBoxLabel">Subscribe to Newsletter?</div>

The above “checkbox”:

• Does not have a name (no label association between label and input)
• Does not have a role
• Is not keyboard focusable
• Does not respond to keyboard events
• Does not have a state associated with it
• Does not have a visual representation of a checkbox field

ARIA to the Rescue

Since we decided to use a custom element as opposed to a native element, it isn’t accessible to everyone and will fall short with accessibility standards. We need to add some ARIA attributes to fix this semantic gap.

<div id="checkBoxInput"

aria-labelledby="checkBoxLabel"

role="checkbox"

tabindex="0"

aria-checked="false">Yes</div>

<div id="checkBoxLabel">Subscribe to Newsletter?</div>

The above “checkbox”:

• Has a name, provided by the ARIA property “aria-labelledby”
• Has a role (added by “role” attribute)
• Is keyboard focusable (added by “tabindex”)
• Responds to keyboard events (requires custom javascript to check for SPACEBAR key changes, then check or uncheck accordingly. See demo below)
• Has an initial state of “checked” equal to “false”
  • added by “aria-checked”
  • also requires custom javascript to update state based on whether or not it is checked (“true”) or not checked (“false”)
• Visual representation provided in demo below

Working demo

At this point, hopefully you can see the “win” with using native HTML vs a custom HTML, Javascript, and CSS solution.

Use ARIA with Caution

No ARIA is better than bad ARIA. After all, it can be complex, which is why it is recommended to proceed with caution when considering implementing it. I’ll leave you with this: Using ARIA is a promise made by the developer that an element’s usage will be familiar and with expected behavior.