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
- 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
- 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
- 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>
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
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:
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.
- HTML links and buttons: whatever the link
text/button value that we provide, it becomes the accessible name
- 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.
The below input text field has visible label but there is no
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>
- Custom widgets: in order to provide the
accessible name for the custom widgets, authors can use either aria-label or