This post begins a series of entries regarding the implementation of Accessible Rich Internet Applications (ARIA) specification in the real world. There are a number of factors that impact ARIA geared development and the user experiences of Assistive Technology users. For example, differing user agents and versions combined with various Assistive Technology types and versions can significantly impact desired functionality; some aspects of ARIA are conveyed by user agents to assistive technologies while others derive from the Document Object Model (DOM).
These are a couple of lesser known details that can seriously impact the functionality of any dynamic component that uses ARIA.
When dynamically adding, removing, or changing ARIA attributes within a focusable element via scripting, it is important to make all such modifications prior to setting focus to that element. Otherwise screen readers may not be able to recognize the purpose/state of the element at that time.
The Sortable Listbox demo at
http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
is a good example of this. When the arrow keys are used to move between list items, the attributes TabIndex=”0″ and ARIA-Selected=”true” are dynamically added to the target LI tag before focus is set to that location, thus ensuring proper functionality and announcement by screen readers. When focus is set to the LI tag prior to setting these attributes, focus is not moved properly and “Selected” is not announced to screen reader users.
Another critical detail regarding ARIA, is that ARIA changes the behavioral nature of elements within the Document Object. This may cause cross-browser compatibility issues in some circumstances for screen reader users.
For instance, the following markup is a standard list.
<ul id=”list”>
<li> … </li>
<li> … </li>
</ul>
Now, through scripting, you can dynamically add the following ARIA attributes to change the list into a listbox:
<ul role=”listbox” id=”list”>
<li role=”option” aria-selected=”true” tabindex=”0″ > … </li>
<li role=”option” aria-selected=”false” tabindex=”-1″ > … </li>
</ul>
(Obviously the scripting would also need to add handlers to toggle ARIA-Selected and TabIndex values appropriately and to handle arrow navigation.)
Now, this works properly in Internet Explorer when using both JAWS and NVDA. However, the entire list disappears when using Firefox with JAWS and NVDA so that screen reader users cannot read or interact with the listbox in any way.
In such a case as this, the only workaround is to copy the contents of each list item, then create new elements in which the contents are added, add the relevant ARIA attributes dynamically, then replace the old list with the new one. The act of rerendering a new list object forces Firefox to convey the proper control types to the screen reader.
The post Lesser known details that seriously impact the usage of dynamically generated ARIA behaviors appeared first on SSB BART Group.