Accessible Rich Internet Applications, widely known as WAI ARIA or just ARIA is a W3C specification to build accessible next generation web technologies. Knowledge of ARIA and its usage is highly increased in modern websites and applications. However, many developers have limited knowledge on the right way of usage. This short article gives ARIA tips and some guidance for developers in the right usage of W3Câ€™s WAI ARIA specifications.
1.Â Â Â Â Â Donâ€™t use ARIA
Yes, you heard right. The first rule of ARIA is â€œDonâ€™t use ARIAâ€. The native elements supplied by markup will give all the accessibility properties such as Name, role, value, keyboard accessibility for free. Developers are not expected to put any additional effort to get those properties. Â Then â€œWhy should you use ARIA?
2.Â Â Â Â Â Donâ€™t use ARIA just because you know it
ARIA is wise to use to fix many semantically incorrect elements, however, many developers use ARIA properties just because they know them. A simple example is using aria-label even a HTML label is available.
<label for=”name”>Your Name</label>
<input type=”text” id=”name” aria-label=”Type your name” />
In the example above, when the screen reader user navigates to the text box it announces, “Type your Name” instead of “Your Name”. What you see is not what screen reader reads.
3.Â Â Â Â Â Use the right attribute at the right place
ARIA specifications define where to use every ARIA role, state and property. Using them with a non-specified element may not give the intended result. Â In addition it may also result in confusion.
In the examples below, aria-checked is not the right state to be used on a button element, however out of ignorance developers use them. In this instance aria-pressed is the right attribute on a button element.
4.Â Â Â Â Â Dual role confusion
Developers out of ignorance or any other reason, may use additional role even for a semantically correct native element. In general, ARIA roles override the properties of native elements. However with some screen reader combinations it may so happen that both the roles are announced for screen reader users. This will confuse them with the element type.
<a href=”#” role=”button”>Continue</a>
5.Â Â Â Â Â Use of non-specified ARIA attributes
In the past, while reviewing the code, it used to so commonly happen that developers use ARIA role, state or property that is not even available in ARIA specifications. This is because developers are not well educated on ARIA specifications. This is the reason why Maxability is concentrating in educating developers and quality engineers through our training courses.
6.Â Â Â Â Â Which ARIA attribute takes priority?
Many times more than one ARIA attribute may be required to use. Sometimes because of various reasons some of those attributes share similar properties. For example, aria-label and aria-labeledby may be used for different purposes on a text box. Though the developers intention is to have the screen reader read the text from aria-label, aria-labelledby takes priority. So again the thumb rule of using ARIA according to the specifications is important.
<strong id=”n1″>Name as appears on Passport</strong>
<input type=”text” aria-label=”Full Name” aria-labelledby=”n1″ />
In the example above both aria-label and aria-labelledby convey similar content with slight variation in the content. Check which one is announced by the screen reader, aria-label or aria-labelledby or both.
7.Â Â Â Â Â Â Build components with ARIA authoring practices
ARIA authoring practices define the techniques and best practices to create highly complex custom components. Following these practices is the best way of baking accessibility in these components. Since the rules are already authored just following them is sufficient. Whatever the reason many developers donâ€™t highly use them. Use W3C WAI ARIA authoring practices.
Here is the easy guide on overview of ARIA roles, states and properties.
Hope these ARIA tips are helpful. With these tips in mind, use ARIA wisely.