Top 5 Rules of ARIA

Before we dive into the rules of the ARIA, let’s reiterate what ARIA does. ARIA stands for “accessible rich internet applications” and helps make web content or web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.

Even though ARIA was created years ago, some of the developers still misuse ARIA due to the lack of thorough knowledge on the subject. Misusing ARIA results in a much more inaccessible experience than when developers do not use ARIA. That is the reason for the common saying, “No ARIA is better than bad ARIA.” That being said,  developers should try to understand and follow the rules of the ARIA, to help provide a more accessible experience to people with disabilities. Let’s dive into the rules of ARIA in greater detail below.

Rule #1: Don’t use ARIA, use native HTML instead

Before you use ARIA,  use native HTML elements or attributes first. In the case that the semantics you are looking for is not available in HTML, then use ARIA.

Let me explain this with the example. To construct the checkbox on a web page, use HTML checkbox (<input type=”checkbox”>) rather than ARIA checkbox (<div role=”checkbox”>…</div>). The reason for this is that HTML checkbox conveys the semantics to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.

Now the question is when to use ARIA. There are a few scenarios where we might have to use ARIA, such as:

• When the website is not designed from scratch and is being retrofitted for accessibility. In this case, it is better to use ARIA in order to save time, effort, and money.
• If it is not possible to style the native element (exceptional cases),  then it is okay to construct the custom element and style and provide the semantics to the element by using ARIA.
• If the required semantics are not present in the host language (HTML 5.x), then use ARIA to communicate the semantics. For instance, if one needs to use ARIA to convey the tree semantics as there is no such equivalent HTML element or attribute.
• When the user agent support of some of the HTML 5.x is not available, then use ARIA.

Rule #2: Do not change native semantics, unless you really, really have to

As previously discussed, most of the HTML elements or attributes convey one or other semantics. We are not supposed to change the native semantics unless it is really essential. An example of this would be if a developer wants to build a heading that is a tab:

Do not do this:

<h2 role=tab>heading tab</h2>

Instead, follow this best practice:

<div role=tab><h2>heading tab</h2></div>

Rule #3: All interactive ARIA controls must be usable with a keyboard

Providing the ARIA roles would bring the semantics to the custom control but it would never bring control to work as expected with the keyboard. We need to remember that ARIA has nothing to do with keyboard functionality, but rather it provides the semantics to the accessibility APIs.

That being said it is the developer’s responsibility to make the custom control accessible with the keyboard by using some scripting. For example, if we construct the custom button(<div role=”button”>) then we need to make sure that it receives the focus and the user is able to activate the associated functionality by using both enter and space keys. To put it in simpler terms, the custom button should work with the keyboard as to how a native button works.

Rule #4: Do not use role=”presentation” or aria-hidden=”true” on a focusable element

Role=”presentation” or role=”none” is to negate the semantics from the accessibility tree and the element that has role= “none” isn’t supposed to be interactive in any way. Similarly, the ARIA-hidden attribute is intended to hide the content or element from the accessibility APIs and the element that has ARIA-hidden set to true is not supposed to be interactive in any way. Defining either of these attributes on the visible focusable elements results in some users to focus on nothing.

Do not do this:

<button role=presentation>press me</button>

Do not do this either:

<button aria-hidden="true">press me</button>

Instead, follow this best practice:

<button role="presentation" tabindex="-1">Don't Click Me</button>
 
<button style="display: none;">Don't Click Me</button>

Rule #5: All interactive elements must have an accessible name

All interactive elements (such as links, buttons, text fields, combo boxes, radio buttons, checkboxes, etc.) on a web page must have an accessible name. Without an accessible name, assistive technologies do not understand what the control is all about. To provide the accessible name, there are techniques available and they vary from control to control. Let us look at some of them.

1. 1. HTML links and buttons: whatever the link text/button value that we provide, it becomes the accessible name
   2. Input text fields: in order to provide the accessible name, form controls need to be associated with its visible label either implicitly or explicitly.
   3. Custom widgets: in order to provide the accessible name for the custom widgets, authors can use either ARIA-label or ARIA-labelledby techniques

For example:
The below input text field has a visible label but there is no accessible name:

First name<input type=”text”>

The below input text field have both a visible label and accessible name. The accessible name(s) establish the ID connection:

<label for=”fname”>First name</label> <input type=”text” id=”fname”>

In Summary

When authors are using ARIA to improve the accessibility of the controls/widgets, the rules of the ARIA must be followed. Failing to follow rules of ARIA while using ARIA may lead to serious accessibility problems. Therefore, we strongly suggest that authors follow the rules of the ARIA while using ARIA on any control to make the web a better place for all the users including people with disabilities.

References: Using ARIA – W3C