Accessibility of AJAX Applications
What is AJAX?
- XHTML (or HTML) and CSS to create an interface and visually style information. The XHTML and CSS elements can be dynamically modified to display new information or styling. These changes are typically done using the Document Object Model.
Using AJAX, web applications can allow high levels of interactivity and processing, but do not require the standard type of client-server interaction, specifically:
- A web page interface is presented.
- User information is collected (via forms, links, etc.).
- The user submits information (submits form, activates link, etc.).
- The server processes submitted information.
- A new web page interface is sent to the user.
With AJAX, all of these steps can be handled in one interface. Examples of AJAX implementation are mapping applications, real-time searches, chats, real-time form validation and processing, live shopping cart applications, e-mail applications, and the list goes on. The types of web applications and interactions allowed by using AJAX has given rise to the term "Web 2.0" — something that surely indicates a major revolution in the way the web can be used. While none of the technologies that comprise AJAX are new or groundbreaking, the increased popularity and awareness of AJAX development brings with it a need for developers to be aware of the accessibility implications these technologies bring.
Why not AJAX?
In general, when content within a page can update dynamically, users should be given control over those content updates, such as by activating a link or button. If content updates automatically without user interaction, there is potential for conflict - if an element that currently has focus is removed or significantly changed, keyboard focus can be lost and a screen reader may become confused. This can often result in focus and screen reader reading to revert to the top of the web page.
As an example, if a page displays updated sports scores every 10 seconds, it's quite possible that the automatic content updates will not be accessible to screen reader and keyboard users. And worse, the rest of the page content may also be inaccessible because they cannot reach it without encountering the dynamically updating content.
WCAG 2.0 requires that content that updates dynamically for more than 5 seconds must provide the ability to pause, stop, or hide that dynamic content. If a pause or hide link is provided, ensure that it is available in an accessible way (e.g., it will be difficult to reach a pause button placed after the dynamic element if that dynamic element causes continual loss of keyboard focus).
In addition to the potential for loss of focus, dynamic content updates may not be apparent to screen reader users. Activating a link or button generally causes a change of context (i.e., the user goes to a new page). With AJAX, the content update may appear in a different location within the same page. In these cases, it is generally necessary to inform the user of this update (perhaps by using an ARIA live region or alert) or by setting focus to the newly updated content area.
While there is nothing inherently inaccessible about AJAX and dynamic updates, special care and testing (including screen reader testing) is often necessary to ensure that it is presented in an accessible manner.