This post is the first in a series that aims to demonstrate how to use ARIA to make complex web pages and applications completely accessible. In this introductory post, I will give you an overview of ARIA that will explain what ARIA is trying to do and how it does it. After reading this overview you should understand how it all fits together, which will help lesson the chance of running into errors.
Introduction to the Introduction
In the old days of accessibility we were told to avoid scripts. (Web Content Accessibility Guidelines (WCAG) 1.0 ([WCAG1], Checkpoint 6.1).) ARIA changed that. Now, instead of stripping down content to make it accessible, we know how to make complex custom controls and dynamic scripted content, etc. accessible. Instead of avoiding scripts we make them inter-operable, which is much better for everyone. Hurray for ARIA! (I needed to put that in... Sorry about that.)
Client-side scripting causes accessibility problems when they do not convey the information necessary to Assistive Technologies (AT) - the devices and user systems typically used by people with disabilities. In simple terms assistive technology needs to know:
1. What things are: The Role. (E.g., I am a checkbox)
2. What they are doing: The state. (E.g., I am now checked)
3. What the relationships are. (E.g., I am labeled by that text, I am part of this group, etc.)
4. Also the focus needs to be accessible from the keyboard and the interaction needs to be predictable. (E.g., you can tab to this checkbox and press enter, then I am checked)
ARIA is a language that lets the author give this information to the user system and AT and sets the focus and flow. That is it. That is all it does. It is simple but it works because that is all that the AT needs. (By the way ARIA is not just for scripts: it also gives AT different information about what things are in a page. But back to those scripts...)
In an HTML checkbox all this information is given in the HTML code. For example, look at the following HTML control:
<input type="checkbox" name=mybox value="1" checked disabled>
Just by following the HTML standard, the AT will know that this control has a role of a checkbox, its state is checked, it has a value of 1 and it is disabled (a property). Further, because an input is a known interactive control, the browser automatically puts it in the tabbing order and it is fully keyboard accessible.
An inaccessible scripted tri-state checkbox might look like:
<span id="my_tristate_checkbox" onmousedown= "My_Checkbox();" > </span>
This checkbox is non-standard. There is no way the AT or user system can be expected to know that the control is span is in fact a checkbox so they do not give it the support that it needs. Also note that as spans are intended for formatting, they are not in the page tabbing order. Hence the scripted checkbox cannot get focus via tabbing.
All the information on roles, state, and properties that were in the HTML check box need to be added to the scripted checkbox.
<span id="ARIA_tristate_checkbox" role="checkbox" aria-checked="false" onClick= "MY_Checkbox();" onmousedown= "My_Checkbox();" ...</span>
Finally we need to make sure that the checkbox events being selected can be selected by the keyboard and not just via touch or a mouse. We also need to add focus to the scripted checkbox, by adding tabindex, so the user can tab to it.
<span id="ARIA_Checkbox" role="checkbox" aria-checked="false" onmousedown= "My_Checkbox();" onkeydown="ARIA_Checkbox_Key(event);" tabindex="0" > </span>
When the script is triggered because the checkbox is clicked, you also need to change the ARIA state.
I would recommend using the standard HTML 5 checkbox because it will work with assistive technologies that do not support ARIA yet. However, there are times when ARIA will give you the missing semantics that HTML just can't, such as tabs, tree items, and described by - but that's for another post. In short, if the roles or relationships or states in your content are not fully captured by your markup, think ARIA. It can usually help.
The core challenges of client-side scripting are:
- Missing semantics, such as state, relationships or roles that are not expressed in standard HTML.
- Controls cannot get focus from the keyboard (for people who can not use a mouse or touch screen).
- Events cannot always be triggered from a keyboard, and require the user to use a mouse or touch screen.
- Changes in content may go unnoticed by users using assistive technology and cannot see the change
- Creation of interface elements that look - but do not operate - like standard controls may be unusable to users of assistive technologies.
Here are my steps to make scripted widgets accessible.
Lisa's 5 ARIA steps:
1. Alert users to each elements role (such as checkbox).
2. Alert users to their properties and important relationships (such as disabled, required,and other labels).
3. Alert users to their original state (such as checked).
4. Alert users to changes in their state.
5. Make sure widgets are keyboard accessible and focus works predictably. Events can be triggered though the keyboard, and it should be intuitive to the user. All controls should receive focus via tabbing though the keyboard.
The next blog will be on using ARIA to make forms more accessible.[hs_action id="8211, 8091"]