I recently provided some base information concerning Accessible Rich Internet Applications (ARIA). I wanted to expand on the topic a bit more. For those who are participating in our monthly Central Illinois Web Professionals meetings, I have been covering this topic in those meetings as well. Before delving into a few more details, I thought it might be helpful to review what makes a web page accessible.
First, one should use semantic markup. If an item is a button, use the proper HTML element; don’t use a <div> and style it to look like a button. I know that seems obvious, but many frameworks ignore this simple approach. Assistive technologies are built to work with semantic content.
Next, provide alternate content as needed. This means a lot more than just alternate text on images. Where possible, the page should be linear (so assistive technologies can process the content). Style the page as desired with CSS, but keep the content available to every visitor. This also helps with search engine rank since most bots scanning a page are looking for valid and semantic HTML.
If your page employs rich Internet approaches (and mimics desktop applications), it is important to define the interactions. I have also observed that it is important to not copy and paste the code from one interaction to another. Yes, this is easily done if you are developing a tabbed interface, for example. However, it is so easy to overlook descriptive information (which can lead to a great deal of confusion when assistive technologies are used on a page). This is part of the reason, I recommend using tools like VoiceOver on a Mac or NVDA on a Windows computer to actually listen to the web page as part of the development process.
Always keep in mind the WCAG 2.0 concept of POUR – your pages should be Perceivable (if I can’t see the content, I should be able to hear it), Operable (whether I am using assistive technology or not, I should be able to interact with the content), Understandable (both the interface and the content should be understandable by those using it), and Robust (a variety of platforms, operating systems and devices should be supported).
For those who are not that familiar with ARIA attributes, there are:
- roles – these describe the actual objects/ widgets (like a tabbed interface)
- properties – these describe the characteristics of the object/ widget (for example, is it required)
- states – these describe the current interaction (is the object hidden, for example).
This is a quick example of some snippets of code indicating how these attributes are employed.
<li id=”item1″ role=”tab”>Content here</li>
<div role=”tabpanel” aria-labeledby=”item1″>more content</div>
There are numerous attributes defined.
- Global states and properties are supported by all elements (regardless if an ARIA role is supplied).
- Widget attributes which focus on objects which receive input and process user interactions.
- Live region attributes which apply to any element and reflect that a part of the page may change (even if there is focus elsewhere on the page). Think in terms of a Twitter stream which is being updated on the page.
- Drag and drop attributes which are used to provide alternate approaches for non visual interactions of this highly visible interface.
- Relationship attributes which describe the association between elements.
The W3C site has a great deal of additional information concerning these ARIA attributes. I tried to summarize some of this information above.
If you would like to see some examples of these ARIA attributes in action, Paul Adams has a wealth of examples. Be sure you view the source code when you are looking at an example.
So, you now know a little more about ARIA attributes. I may continue further discussions on this in a future weblog post. However, I wanted to discuss one item which is becoming more and more of a concern to me these days.