Web Accessibility(A11y): WAI-ARIA Attributes
Introduction
In the previous story, we learned about the importance of web accessibility and how we can achieve that using standard HTML, CSS, and JS. We have learned that WAI-ARIA defines a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve openness wherever it is lacking for Assistive technologies(using OS APIs).
From an HTML angle, WAI-ARIA provides extra attributes applicable to all HTML elements. An important point about WAI-ARIA attributes is that they don’t affect anything on the web page, except for the information exposed by the browser’s accessibility APIs
In the previous story, we have also learned that Accessibility does not just mean “blind users with screen readers”, but sighted keyboard users, users with colour blindness/deficiencies, deaf/hard of hearing users, users with cognitive disabilities. however, ARIA is (almost) exclusively about how to ensure that web content is correctly conveyed to assistive technologies (screen readers, screen magnifiers with screen reading capability, etc)
Assistive technologies
Software or Applications which help the differently-abled people to use web/other applications like a normal user are Assistive technologies.
- JAWS
- ZoomText
- NVDA (free)
- VoiceOver (free)
- TalkBack (free)
- ChromeVox extension
All these tools and application depends on OS-specific APIs for Accessibility and they help the differently-abled people to use web application like a normal user
Web-based Assistive technologies depend on WAI-ARIA attributes and semantically correct HTML Elements to work seamlessly for a differently-abled person, basically, they act as bridge b/w OS Accessibility API and WAI-ARIA attributes instructions.
WAI-ARIA Categories
There are three main features/categories defined in the spec for these WAI-ARIA attributes:
- Roles: it defines what an element is or does. it provides only one attribute which is ROLE, such as
role="banner",role="search",role="tabgroup",role="tab"for a complete list of the role, visit MDN reference here. Each role further has different WAI-ARIA attribute applicable to that particular role egaria-pressedwai-aria attribute will be available to use when you specifybuttonrole on your element. (Roles are categorized as Abstract Roles, Widget Roles, Document Structure Roles, Landmark Roles, Live Region Roles, Window Roles. Please find their details in above MDN reference)
- Properties: These define the properties of elements, which can be used to give them extra meaning or semantics. As an example,
aria-required="true"specifies that a form of input needs to be filled in to be valid.
- States: Special attributes that define the current conditions of elements, such as
aria-disabled="true"
When should you use WAI-ARIA?
We talked about custom button problems in the previous story that prompted WAI-ARIA to be created earlier on
Essentially, there are four main areas that WAI-ARIA is useful in:
- Landmarks: To specify the landmark/section on your web page using role attribute eg. specify search role to search section as we have seen above
- live-updates: static text can be easily accessed by screenreader but modern web page load most of the content dynamically and aria-live attribute helps us to specify the accessibility of area whose content will load dynamically into DOM using web APIs. Applying this attribute to an element causes screenreaders to read out the content that is updated, How urgently the content is read out depends on the attribute value:
polite: Updates should be announced only if the user is idle.assertive: Updates should be announced to the user as soon as possible.off:The default. Updates should not be announced.
Below is the sample code to understand how aria-live can be helpful for the screen reader to read the dynamically available content.
keyboard accessibility: As discussed in a few other places in this article, one of the key strengths of HTML with respect to accessibility is the built-in keyboard accessibility(tabbable) for an element like Button, but for complex controls, this will not be available by default but to make them keyboard accessible(particularly using the tab key to move between controls), WAI-ARIA extends the tabindex attribute with some new values:
tabindex="-1"— this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links.
non-semantic controlstabindex="0"— this value allows elements that are not normally tabbable to become tabbable. This is the most useful value oftabindex.
What ARIA doesn’t do…
ARIA is not magic: it only changes how assistive technology interprets content. specifically, ARIA does not:
- make an element focusable
- provide appropriate keyboard bindings
- change browser behaviour
- automatically maintain/update properties
- change visible appearance
all of this is still your responsibility…
No ARIA is better than bad ARIA
- ARIA roles/attributes are a “promise” to users / assistive technologies (e.g. “this component is actually a button…”) — you must ensure that it then behaves correctly
- if you’re not sure how to represent a particular complex widget or control, don’t just throw ARIA roles and attributes at your markup — you’re more likely to make things worse / more confusing / non-functional for assistive technology users
List of Popular/Important ARIA Attribute
- aria-required
- role
- aria-label
- aria-labelledby
- aria-disabled
- aria-selected : tab selection
- aria-hidden
- aria-checked
- aria-expanded
- aria-setsize
- aria-posinset
Complete list of all properties and state-based ARIA attribute can be found here
Tools
There are a number of tools available to test the accessibility in your web application or website. W3.org has listed all Accessibility evaluation tools Here, I have not tried all of them but checked a few of them and also found some of them are outdated.
I personally using
- ChromeVox Classic extension to test screen reader based accessibility for my application
- VoiceOver screen reader available on mac by default
- Also using a11y-checker open-source automated tool to test accessibility issues in HTML markup. I have found this in w3.org listing. this is quite good and support all modern front-end framework like React.
- There are extension and plugins available for all major Text editor starting from VSCode(I have not tried anyone as of now)
- All major browsers support Accessible Tab/Pane to view accessibility tree, ARIA attributes, and computed accessibility properties of DOM nodes.
- From Chrome V84 onwards Accessibility info of element also available as a tooltip on hovering element in inspect mode
- Use Chrome Audit panel to determine if A page is properly marked up for screen readers.(Chrome Accessibility testing Reference )
If you have better tools or toolchain then you can share the same in the comment section.
The accessibility tree
The accessibility tree is a subset of the DOM tree. It only contains elements from the DOM tree that are relevant and useful for displaying the page’s contents in a screen reader or Assistive Technologies.
Conclusion
Like the previous story, this story is based on my learning experience from different resources over the internet mostly from MDN.
In this story, I have tried my best to provide the usage details of WAI-ARIA Attributes and How they help the Assistive technologies based Application like screen-reader to provide web content accessibility to differently-abled people.
In some section, I have provided a detailed reference of MDN resources, I would prefer to go through them. I will try to provide a detailed case-study on “Enabling Asseccabilty in complex widgets like Calendar & ProgressBar ” in future till then Stay Safe! and don't forget to provide the feedback in the comment section.
Happy Coding!
