Detailed View on Accessibility Problem
Although, using the generic elements results in a widget that appears just like its desktop counterpart, it lacks the required semantic information in the markup – the very same markup that is used by an assistive technology. This results in some users being unable to view dynamic content. Besides, live twitter feed updates and similar content, make alterations to the DOM that an assistive technology (AT) may not be familiar with.
This is where WAI-ARIA comes in.
Before understanding what WAI-ARIA is and how it helps to overcome the accessibility problem, let us first consider an example, where markup for the “tabs” widget is created without using ARIA.
When the above code is executed, the users will visually see a tabbed widget. However, the machine-readable semantic that most assistive technologies need is not available.
Introduction to WAI-ARIA
ARIA or WAI-ARIA, the “Accessible Rich Internet Applications Suite” – is a W3C’s Recommendation that defines a way to make web content and applications accessible to users with disabilities. More specifically, WAI-ARIA enables developers to add more attributes to the markup, so as to help users identify features to interact with. This includes the complex controls that most websites and web-based applications are using today.
The WAI-ARIA specification consists of three different attributes: roles, states, and properties. These WAI-ARIA attribute types help developers with the following:
- Roles describe some of the well-known UI widgets presents that are not available in HTML – be it sliders, tabs etc. They also describe page structure including headings, tables, etc.
- Properties describe the state of widgets. For instance, whether a widget is “draggable”, has a popup associated with it and so on.
- States describe whether an element can interact or not. Putting it simply, ‘states’ inform the assistive technology whether the state of element is busy, disabled, selected, or hidden.
Now let us consider an example. Let’s say, a markup for the “tabs” widget with WAI-ARIA attributes added.
How to Make Presentational changes With WAI-ARIA?
In order to make dynamic presentational changes, CSS is used. This is because it facilitates changes in the appearance of content and is namely used for showing or hiding it. The dynamic presentational changes include:
State changes: WAI-ARIA provides three type of attributes to determine the state of a UI widget, such as:
- aria-checked: declares the current state of a checkbox / radio button.
- aria-disabled: specifies to check whether an element is visible, but cannot be edited.
- aria-grabbed: defines an object’s ‘grabbed’ state in a drag-and-drop operation.
Visibility changes: In case changes are made to content visibility (that is the content is hidden or shown), it is important for developers to change their aria-hidden property value accordingly. During CSS declaration, developers can hide an element visually by using the CSS attribute ‘display:none’.
Role changes: Lastly, WAI-ARIA empowers developers to introduce a semantic role for each element – that offers inaccurate or no semantics. For example, while using an unordered list for creating a menu, the ‘ul’ should assigned a role of ‘menubar’ and ‘li’ should be assigned a role of ‘menuitem’. A word of caution: make sure to keep the role of the element the same. It shouldn not be changed. However, you can choose to get rid of the original element and substitute it with an element with a new role.