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).
The reason there is a need for ARIA on web pages is that there is no HTML element for items we use all the time on a desktop application (such as sliders, tbs and so forth). Therefore, many developers (and frameworks) take generic elements like <div> and style them with CSS and JavaScript to perform these functions. For those who can physically see the page, everything looks fine. The problem happens when one tries to use assistive technologies to view the page content and there is not sufficient semantic information. It is up to us as web page creators to employ ARIA properly when there is a business need to desktop like interfaces.
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.
<ul role=”tablist”>
<li id=”item1″ role=”tab”>Content here</li>
</ul>
…
<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.
We all rely more and more on JavaScript frameworks to handle a lot of the “heavy lifting” as we develop web sites. However, these frameworks are not all “created equal” and many seem sadly lacking in the area of support for ARIA. Yes, that was sort of a verbal pun (area for ARIA). Consider this Wikipedia comparison of JavaScript frameworks (yes, it is a bit out of date and many frameworks are lacking). If you follow the above link, make it a point to do a find on the word accessibility (CTRL+F or CMD+F on a Mac) while you are at that page. I have included a screen capture below of the pertinent part. No, you don’t need to be able to read it. Instead focus on the areas which are not in green (meaning support is lacking or worse). The top row names the framework, the area highlighted below indicates whether that framework is accessible. Note the lack of green across all the options.
If you are planning to work with a JavaScript framework, I recommend you give serious consideration to testing how accessible it is before deploying it. The WWW should be accessible to all (any device, any time, anyone).
Loading ...
