Five Golden Rules of ARIA To Support Accessibility
“Accessibility allows us to tap into everyone’s potential.” – These wise words by Debra Ruh, a keen advocate for accessibility rights of people with disabilities, and the founder of TecAccess are the need of the hour.
As we grapple with the unprecedented COVID-19 pandemic across the globe, it is vital to highlight web accessibility. Fifty-seven million Americans have a disability – that’s a number that you cannot afford to exclude from access to digital content and information.
The five major categories of disabilities include:
Let’s understand web accessibility in detail. It refers to the practice of creating inclusive digital content and mobile applications that can be easily used by people with disabilities. Not only the disabled, people living in rural, underdeveloped areas, and the aged population can benefit through accessible content.
Various assistive technologies can help people with disabilities to access electronic content without any difficulty. For example, learners with visual disabilities may use a screen reader to navigate digital content on computers or mobile devices. Creating accessible content is not an option anymore; it is a necessity to enhance global reach for people from all walks of life!
The Role of WAI-ARIA In Web Accessibility
ARIA is a technical specification in the field of digital accessibility. It has been published by the World Wide Web Consortium (W3C) and provides a blueprint for creating accessible, dynamic content. ARIA provides users with a markup that can be used with HTML components to provide vital data about assistive technologies. This provides the right level of support and makes information easily understandable and inclusive in all digital formats.
Even though ARIA has been prevalent for a few years, there is a lack of awareness amongst digital content developers. The WebAIM Million Report was recently updated and revealed that website home pages with ARIA present on an average displayed 60% more errors in design than those without – this depicts the need to throw light on rules of ARIA that can prevent common mistakes!
Rule #1 Try To Use Native HTML Elements
HTML is the pillar stone for web accessibility. Developers should avoid using ARIA until required, as an incorrect application may lead to accessibility barriers. If a native HTML attribute provides the required semantics for accessibility support, avoid using ARIA components on your webpage.
Rule #2 Avoid Altering Native Semantics
Most HTML elements contain default semantics with implicit meaning that help learners with screen readers and other assistive devices. When an ARIA role is added, it often overrides the original semantics of the HTML element and leads to unwanted changes.
For example, a <ul> can be used to define an unordered list. A screen reader will come across this element and instantly identify it as an unordered list. It will also be able to announce the number of items in the list and enable navigation through the list. If we add a specific ARIA rule to the element <ul> such as <ul role=”navigation”>, then the native semantics get overridden completely. This means that the element is now a navigation landmark and the accessibility benefits no longer remain for the unordered list.
A better option would be to apply – <div role=”navigation”><ul>…</ul></div> to retain the navigation landmark, and ensure that the unordered list is accessible to all users.
Rule #3 Ensure Interactive ARIA Attributes Are Accessible Through Keyboard
ARIA Design Pattern demonstrates how to make ARIA widgets accessible by all mediums and stresses on providing keyboard support. Keyboard functionality cannot be ignored as it can hamper the user experience for disabled people. Developers must make custom control accessible through device keyboards by scripting, and buttons should be clickable with a cursor, enter key, and space bar.
Rule #4 Interactive Controls Should Have Semantics For Visibility
It is essential to keep interactive ARIA elements visible. When we use role=” presentation”, all semantics are removed; hence we should not apply it on a focusable element. Similarly, aria-hidden =” true” hides focused elements for screen readers and prevents users from interacting with functionality.
Rule #5 Make Sure To Keep Accessible Names For Interactive Elements
Developers need to ensure that interactive controls such as buttons, links, text fields, and checkboxes have an accessible name. ‘Accessible Name’ is a term used for the content screen readers announce to identify an element. ARIA can be used to develop visible and accessible name labels.
Not using ARIA is better than misusing it! Web authors need to follow the rules of ARIA to curate an accessible experience for disabled users. A specialized markup enables users to communicate semantics; ARIA is perfect for defining the role of an element in the web interface. Make the web a more inclusive and better place, and follow ARIA rules to create genuinely accessible content.