ARIA, or Accessible Rich Internet Applications, is a set of attributes that define ways to make web content and web applications more accessible to people with disabilities. ARIA attributes can be added to HTML elements to provide additional information about their role, purpose, and state. This information can be used by screen readers and other assistive technologies to provide a more accurate and informative experience for users.
There are many different types of ARIA attributes, each with its specific purpose. Some of the most common ARIA attributes include:
Role attributes: These attributes define the semantic role of an element, such as button, menu, textbox, or slider.
State attributes: These attributes describe the state of an element, such as checked, disabled, or expanded.
Property attributes: These attributes provide additional information about an element, such as its value, label, or description.
<a href="/about" aria-label="About page">About</a>
<h1 id="about-heading">About</h1>
<a href="/about" aria-labelledby="about-heading">About</a>
<p id="about-description">This is the about page.</p>
<a href="/about" aria-describedby="about-description">About</a>
<button type="button" aria-role="menu">Menu</button>
<div aria-hidden="true">This element is hidden from assistive technologies.</div>
<button type="button" aria-disabled="true">Disabled button</button>
5 Rules of ARIA Use
When using ARIA, there are some dos and don’ts that must be followed to ensure that your site or the project you’re working on is accessible to users who rely on screen readers and other assistive technologies. These are known as the Rules of ARIA and they are five in number:
Rule 1
The first rule of ARIA use goes as follows;
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible**, then do so.**
This means it’s best to use semantic HTML where it is available as much as possible and not resort to using elements like div in place of button element and adding ARIA roles, states, or properties to make such elements accessible. There are some instances in which this might not be possible and they include:
The feature is currently not available in HTML
If the visual design constraints rule out the use of a particular native element because the element cannot be styled as required.
When the native HTML element does not have accessibility support.
Rule 2
The second rule of ARIA use warns against the changing of native HTML semantics with ARIA roles, states, or properties. Do not change native semantics, unless you really have to. For example;
Do not do this
<h2 role=tab>heading tab</h2
Do this
<div role=tab><h2>heading tab</h2></div>
Rule 3
The third rule of ARIA use states that all interactive ARIA controls must be accessible via the keyboard. This means that whatever action (drag, drop, click, etc.) elements on a page require to act, users must also be able to perform the equivalent using just the keyboard.
An example of this would be submitting a form using a button. A user must be able to submit the form by clicking on the enter or return button, which must also be capable of receiving focus.
Rule 4
The fourth rule of ARIA use warns against the use of the role attribute with presentation and aria-hidden='true' on elements that are visible and focusable to the user. Doing either of these would result in the user focusing on nothing in the end.
Do not do this
<button aria-hidden="true">press me</button>
Only use aria-hidden='true' on elements that aren’t visible or cannot be interacted with but are interactive.
button {visibility:hidden}
<button aria-hidden="true">press me</button>
Note:- If an interactive element is hidden using display: none, it will also be removed from the accessibility tree, which makes the addition of aria-hidden="true" unnecessary.
Rule 5
The fifth and final rule of ARIA states that all interactive elements must have accessible names, like **.** the name of a user interface element.
Take this example:
<label>Email</label>
<input type="email" />
This is wrong because assistive technologies would not be able to connect the label value to the input field and its users would also struggle to understand that the field is meant for their email address. Instead, do either of the following:
<label for="email">Email</label>
<input type="email" name="email" id="email">
<label>
Email
<input type="email">
</label>
Conclusion
ARIA is a powerful tool that can be used to make web content and web applications more accessible to a wider range of users. By using ARIA correctly, you can create a more inclusive and user-friendly experience for everyone. ARIA can be used to improve the overall usability of your website and to provide more descriptive labels for links and buttons or to make interactive elements more keyboard-accessible.
Happy Coding !!
