What is Ajax (and what is it not)? Part 3 of 3

Posted in Accessibility, Ajax / Scripting, Resources, Web Standards

AjaxThis is the third post (of three) discussing the topic of Ajax. If you haven’t already done so, you might want to go back and read Part 1 (general introduction, definitions, and history) and Part 2 (development sandbox with examples). Now that I’ve covered the basics of Ajax and implemented some demos, I’d like to address the issue of Ajax accessibility. Does the use of Ajax necessarily exclude people with disabilities? Does Ajax cause a roadblock for search engines (search engine optimization) and mobile devices? Are there ways to improve the accessibility of Ajax and JavaScript-enhanced websites?As I’m writing this, I’m wondering what kinds of accessibility concerns there are in the sandbox demos I included in Part 2 of this series. Did you notice some issues as you were trying out the demos? Perhaps I’ll have to put them to the test in a more formal manner… but that’s a task for another day (and another blog post). In this post I’d like to discuss some general accessibility issues and possible solutions that are available to web developers today. It’s by no means an exhaustive list or a definitive hands-on guide, but hopefully it’s a good starting point for further research.

Simple Interactions

I think the first point that needs to be made is that Ajax, by definition, requires the use of JavaScript. Even if you’re not making a call back to the server using the XMLHttpRequest object, JavaScript is a key component in many websites today using an increasing number of animated browser effects. That’s not a bad thing by itself. But what if JavaScript is disabled or not available? For instance, some mobile devices have limited, if any, JavaScript support. Some screen readers have better JavaScript support than others. Search engines are unable to follow JavaScript constructed links, so search engine optimization strategies could be hindered. For all of these cases, developers need to provide an alternate means of reaching the website’s content. However, creating two different versions of the same content can be a maintenance nightmare as well as an expensive development option. What if there was a better way? Let’s take a look at some alternatives that might offer some assistance to web developers.

Creating New Scripting Habits

Before we get into the more complex Ajax examples, let’s start with the simpler methods, such as JavaScript enhanced links. In a book called Bulletproof Ajax, Jeremy Keith presents a new method which I find very useful. He calls it hijax and it is built on the idea that you can “hijack” regular links, through the use of DOM scripting, to add an unobtrusive behavior layer to your web pages. Without this layer, the links still work as expected, but if JavaScript is available, the user gets an enhanced experience. Jeremy encourages us to avoid bad habits of the past where we used scripting methods that caused accessibility issues. Here are two methods in particular to avoid:Using the JavaScript pseudo-protocol:

1
<a href="javascript:window.open('help.html')">contextual help</a>

Using a fake link:

1
<a href="#" onclick="window.open('help.html'); return false;">contextual help</a>

A better method uses a real link with some added scripting. If JavaScript is unavailable, the link still works:

1
<a href="help.html" onclick="window.open(this.getAttribute('href')); return false;">contextual help</a>

But, we still have some inline JavaScript and that’s not always the best way to go. Here’s where things get exciting. How about creating a normal link and add a CSS class that can be “hijacked” by a simple JavaScript function?Here’s the HTML code:

1
<a href="help.html" class="help">contextual help</a>

…and here’s the JavaScript function to go along with it:

1
function doPopups() {if (document.getElementsByTagName) {var links = document.getElementsByTagName("a");for (var i=0; i < links.length; i++) {if (links[i].className.match("help")) {links[i].onclick = function() {window.open(this.getAttribute("href"));return false;};}}}}

See how that works? The doPopups function creates an array of all the links on the page and then adds an onclick event (the popup window) for any links that have a class of help. This is a very simplified example of Jeremy’s hijax concept. There are additional recommendations for dealing with data retrieved via the XMLHttpRequest object which are more appropriate for true Ajax development methods. I encourage you to check out his excellent books, Bulletproof Ajax and DOM Scripting for additional details.

More Complex Interactions

When it comes to more complex Ajax methods, the subject of accessibility becomes even more important. Some Ajax techniques dynamically add new content to the page in a way that might not be obvious to the casual observer (or completely hidden in the background and therefore invisible to the user). This situation becomes critical for screen reader users since they may not get any sort of notification when the page has been updated and therefore the screen reader may not read the information. Imagine how frustrating it would be to fill out a form and receive no feedback about potential errors. You click the submit button and it just returns you to the form. In order for dynamic page updates to be accessible, there needs to be a way of effectively notifying the user so that they can read the new content.

Accessible Rich Internet Applications (WAI-ARIA)

There’s so much more that can be done to make Ajax (and other complex scripted interactions) more accessible. The Web Accessibility Initiative is currently developing a specification called Accessible Rich Internet Applications (WAI-ARIA) that enables web developers to create web applications in a more accessible way.

Keyboard Navigation

Being able to navigate a website using the keyboard alone (without the aid of a mouse) is an essential requirement for basic accessibility. By default, only links and form elements can receive focus (make it available for user interaction). Try it out for yourself and you’ll see what I mean. Start at the top of a web page and press the Tab key several times to “focus” links and form elements as you go down the page. However, a dynamically displayed error message, for example, wouldn’t be focusable for keyboard-only and screen reader users. Therefore it would likely be missed altogether. WAI-ARIA helps alleviate this problem by enabling all visible elements to be focusable by extending the tabindex attribute in HTML.

Roles, States, and Properties

WAI-ARIA provides the role attribute to help define widgets (sliders, tree menus, etc.) and page structure (sections, navigation, etc.). See the full list of roles available. Additional information about how a user can interact with a widget can be provided with WAI-ARIA’s states and properties. See the full list of states and properties available.

Live Regions

Areas of a web page that will change dynamically using Ajax can be specified as live regions. Live regions provide a mechanism for notifying the assistive device (such as a screen reader) that new or updated content is available on the page and how the user should be notified about the content. The WAI-ARIA specification provides additional information on live regions.

Additional WAI-ARIA Resources

I’ve included only a few of the many features available with WAI-ARIA. Here are some additional references available for further reading.