Developers working on DHTML user interfaces should keep in mind, at the very least, the following techniques:
Comprehensive keyboard controls are often overlooked by developers, but are one of the best ways to improve the overall accessibility of your design. A large number of assistive technology users depend on the keyboard to access everything on the web; keyboard accessibility also improves efficiency and convenience for all users.
The basic rule is this: everything that is available with the mouse should also be usable by keyboard. This includes any kind of direct manipulation tasks such as drag and drop, as well as hover effects, tooltips, and similar behaviour.
Here's an example of how you would use the tabindex attribute for a typical menubar interface:
For more detailed information about keyboard navigation, check out the Mozilla Developer Center's Key-navigable custom DHTML widgets article.
To test your browser's handling of the tabindex attribute, consult the Tabindex Focus Navigation Tests article.
Here are some techniques to make your code more portal-friendly:
Multiple Placements: Another complication is the issue of multiple placements of the same portlet. In a portal, more than one instance of a portlet can appear on a single page. This requires all markup to be unique to each instance of the portlet such that there won't be conflicts or ambiguity when manipulating DOM elements by id. In other words, ensure that your generated markup includes a unique prefix for all element ids. This additional level of markup namespacing can be provided by tools such as the Portlet taglibs for JSP, or the built-in functionality of a portlet-friendly presentation framework such as RSF.
The biggest accessibility problem with DHTML is a lack of semantics. Most Web 2.0-style user interfaces bring richer controls similar to those found on the desktop. The problem is that HTML doesn't provide enough built-in information to properly describe these types of controls to users of assistive technology.
Current assistive technology is well-equipped to work with common UI controls found on the desktop. Indeed, the fact that many DHTML widgets more closey mimic their desktop counterparts provides the opportunity to make the web much more accessible and familiar than it has previously been. The challenge is ensuring that the assistive technology knows enough about the meaning of the markup to correctly represent these controls. In other words, we need to add additional information to the markup in order to ensure that assistive technologies understand the characteristics and behaviour of our DHTML user interfaces.
At the core of the DHTML accessibility problem is a lack of UI semantics; HTML doesn't give us enough richness to properly describe user interfaces to assistive devices. DHTML controls are often built using generic grouping elements such as
<span>, or by overloading existing types such as lists. These tags don't provide us with any further indication of what the control does, or what properties and states it possesses. So imagine a tab-based navigation bar in a web application. The markup might look something like this:
<ul id="tabNavigation"> <li class="tab">Home</li> <li class="tab">Books</li> <li class="tab">Music</li> <li class="tab">DVD</li> </ul>
While the markup may look and feel like a group of tabs visually, we have no explicit labels or semantics to communicate this behaviour to the browser and assistive technology.
ARIA's goal is to fill in the semantic gap missing from HTML. Created by the W3C, ARIA is a specification describing additional markup for Accessible Rich Internet Applications. It allows you to add specific attributes to your XHTML elements in order to help specify the roles, properties, and states of a particular interface control. Roles describe the type of user interface control, for example: menus, tabs, sliders, grids, trees, and tool tips. States and properties describe the various modes or settings a control can have, for example: disabled, selected, busy, readonly, etc.
Using ARIA, our tab example above would look like this:
<ul id="tabNavigation" role="tablist"> <li class="tab" role="tab">Home</li> <li class="tab" role="tab">Books</li> <li class="tab" role="tab">Music</li> <li class="tab" role="tab">DVD</li> </ul> <div role="tabpanel"> The contents of the tab panel go here. </div>
The addition of the namespaced ARIA roles for tabs, tablists, and tabpanels will be sufficient to convey the meaning of the interface to users of assistive technology, ultimately making this interface far clearer and more accessible to all users.
While ARIA takes a bit of work to understand, it is fundamentally required to make DHTML user interfaces accessible to a broad range of users. The added benefit is that ARIA provides further semantic richness to your markup that can be used for CSS selectors, DOM manipulation, and so on.