Rules of ARIA

Overview

Before we dive into the rules of the ARIA, let me reiterate what ARIA is going to do. ARIA stands for accessible rich internet applications and it defines the way to make the web content or web applications more accessible to people with the disabilities.

Even though ARIA has evolved couple of years ago, still some of the developers misuse the usage of the ARIA due to the lack of thorough knowledge . Misusing of the ARIA results much more damage to the web page in terms of it’s accessibility. That is the reason there is saying “No ARIA is better than bad ARIA!“. Having said that, if developers understand and follow the rules of the ARIA then definitely it is going to help to certain extent in avoiding some of the mistakes. Let us understand what are those rules of the ARIA in details.

Rules of the ARIA

Rule1: don’t use ARIA, use native HTML instead

The first rule talks about use native HTML elements or attributes to convey the semantics to the people with the disabilities. In the case, the semantics that you are looking for is not available in the 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”>) but do not use ARIA checkbox(<div role=”checkbox”>…</div>). The reason is that HTML checkbox conveys the semantics to the people with disabilities without any additional effort as it is already mapped to the accessibility APIs. Now the question is when to use ARIA. There are some scenarios where we might have to use ARIA and they are:

• When the website is not designed from the scratch and is being retrofit for an accessibility then it is better to use ARIA in order to save time, effort,  and money
• If it is not possible to style the native element as per need for some reason(exceptional cases)  then it is ok to construct the custom element and style as per the need 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 the instance, 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 great then use ARIA without any second thought.

Rule2: Do not change native semantics, unless you really have to.

As discussed earlier, 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. For example: Developer wants to build a heading that is  a tab

Do not do this:

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

Do this:

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

Rule3: All interactive ARIA controls must be usable with the 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 is nothing to do with the keyboard functionality and is just to provide the semantics to the accessibility APIs. Being said, it is developer 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 user is able to activate the associated functionality by using both enter and space keys. To put it simpler, custom button should work with the keyboard as how native button works.

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

Role=”presentation” or role=”none” is to negate eh semantics from the accessibility tree and the element that has role= “none” is not supposed to be an interactive in any way. On the similar lines, Aria-hidden attribute is 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 an interactive in any way. Defining either of these attributes on the visible focusable elements results some users focus nothing.

Do not do this:

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

Do not do this either:

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

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

Do this:

<button role=”presentation” tabindex=”-1″>Don’t Click Me</button>

<button aria-hidden=”true” style=”display: none;”>don’t Click Me</button>

Rule5: All interactive elements must have an accessible name.

All interactive elements(such as links, buttons, text fields, combo boxes, radio buttons, checkboxes and so on..) on a web page must have accessible name. Without 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 some of them.

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 it’s visible label  either implicitly or explicitly.

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

   First name<input type=”text”>

   The below input text field have both visible label and accessible name. Accessible names establishes with the for and ID connection

   <label for=”fname”>First name</label>

   <input type=”text” id=”fname”>

3. Custom widgets: in order to provide the accessible name for the custom widgets, authors can use either aria-label or aria-labelledby techniques

References

• Using ARIA – w3c