Websites with features described as AJAX have become incredibly common in the last few years. Many of these sites are even using AJAX—and a few of them are even using AJAX well. Many, however, have significant problems in their implementation, especially where web accessibility is concerned.
Despite its popularity, AJAX is not one of the best-understood areas of web development, even for web developers.
Part of the confusion comes from the combination of poor semantics and the simultaneous rise in popularity of dynamic JavaScript libraries and increasing interest in creating web pages that behave more like desktop applications.
What Are AJAX and Dynamic JavaScript?
The acronym AJAX stands for "asynchronous JavaScript and XML." The key term in that is “asynchronous.” Asynchronous behavior in a website means that the site can send a query back to the server without requiring the entire page to be refreshed. The page is refreshing (re-rendering) just a portion of the page, rather than the entire document. This can have a significant boon in both the apparent and the real speed of a web application.
Technically, a legitimate AJAX request neither needs to be asynchronous nor does it need to work with XML, but these features are the particular characteristics that make AJAX behaviors recognizable.
Dynamic behaviors involve changing the appearance of the information on the website using JavaScript. Rather than making a query to the server, they simply update the available view of the information for the user, such as switching tabs, opening an accordion menu, or showing a drop-down menu. The only real difference between AJAX and more standard JavaScript may be whether the page fetches new information from the server or not.
Although many web designers and developers may know the distinction intuitively, it can still be hard to explain to clients or co-workers.
So When Should You Use AJAX?
Generally, you don't want to make a server call and, therefore, use "real" AJAX unless the information that will be shown on page is dependent on user input or unless a significantly different state of the information is required. If the information is the same regardless of what the user does, then you have no need to make that extra server request. You can simply incorporate the text into the website and reveal it on request via dynamic JavaScript.
AJAX and Web Accessibility
In both cases, the choices you make may have a significant effect on web accessibility and on search engine performance.
First, the simpler case: basic dynamic JavaScript.
One of the most common uses of dynamic JavaScript is to hide and reveal blocks of information. This activity requires three elements: a hidden block of text; a visible trigger to reveal the block of text; and a script to hide or reveal the text.
Really, it's pretty simple. But the simplest things can trip up the unwary. In this case, it's simply the order and way in which the tasks are done.
For this to make sense, clearly the hidden text needs to be concealed from the user when he or she reaches the website. Many web developers will then seize on the obvious choice: conceal it in the cascading style sheet (using display:none;, usually,) then use JavaScript to reveal it.
And that's a problem.
For any user agent visiting your site without full access to JavaScript, this may leave it unable to reveal that hidden text. This includes older search engines and mobile devices in particular. Is a search engine going to fully appreciate text that it can see is intended to be hidden? If the text is hidden, then it's not intended to be used.
Instead of hiding the text using style sheets, the block should be hidden using JavaScript. If JavaScript can trigger the reveal, it can certainly trigger the hide as well – and in this case, any user without sufficient JavaScript to reveal the text will also be unable to hide it, leaving the full text available for those users.
When you get into real AJAX, the issues get more complicated. Most of the time, AJAX requests are going to be driven by a form submission, data requests, or material updates. The nature of AJAX is to take input and provide a response, so in order for the responses to be meaningful, it needs user or browser input.
And from the user's perspective, AJAX can cause some accessibility problems. In a "normal" website interaction, the process for a login form, for example, is something like this:
- Enter username and password.
- Press submit.
- Screen refreshes and indicates either that you've successfully logged in or that your user name and password were not accepted.
If that form is AJAX driven, however, your experience may be like this:
- Enter user name and password.
- An area on the page refreshes and informs you whether or not you have successfully logged in.
The form submission may have been dynamically triggered simply by your leaving the form fields; and the form response may not require a refresh. This can be convenient for most users as it saved having to click the mouse once (or worse resubmitting information), and saved the time required to refresh the page. It's not so valuable for accessibility-challenged users if implemented poorly.
A screen reader, which blind and disabled consumers use, may not be aware that anything has changed. Because screen readers handle data in a linear fashion, they'll only notice the form's response if it follows after the form. This can be very confusing —the user won't have seen a submit button, and not seeing any response after submitting the form, he or she has an unwelcome challenge to determine whether anything has happened.
Fortunately, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) has provided methods that can be used to escape this flaw. In this particular case, the use of a WAI-ARIA live region would be effective.
Live regions are areas of a website which are identified as having dynamically updating content. They can be specified as having various properties for their announcements: off, polite, assertive, and rude.
In the case above, you'd probably want to use the “polite” or “assertive” settings. “Polite” means that the user will be notified that a change has occurred and be given the opportunity to navigate to that region immediately. “Assertive” means that the user will be specifically notified of the update as soon as possible after the event. In either case, the disabled user will be notified of an event following his action and will be able to easily navigate to the response message.
Summary
AJAX is certainly a powerful tool for site development, and one that should be in your bag of development tools. But it can also have some unexpected consequences for disabled shoppers. So please apply it with care.
