The use of Javascript to add interactive components to websites has become commonplace. Whether you use jQuery, Mootools, Yahoo UI or any of the other popular JS libraries to enhance the user interface, AJAX really helps to add fluid interaction driven by server side data, without requiring the entire page to reload. (or AJAJ if you like JSON like I do, let’s just say the ‘X’ stands for ‘any structured data format’)
If you’re serious about accessibility, you’ll also keep the WCAG in mind. One of its requirements is that you should never hide content behind a technology with limited availability. So, no information presented in a Flash application if you don’t offer a non-Flash alternative. Strict supporters of such guidelines take it one step further and demand that all functionality, even the features you add for convenience or plain bling, is essentially available if most of the supporting technology is turned off.
The reasoning goes a little like this: a website is there to perform a function or provide information. If people want it to look nice, they can have CSS. If they want interaction and save time on page reloads, they can have Javascript. If there is something that absolutely requires more than a webbrowser has to offers (at the time), you can consider writing a Flash application. Video used to be such an application, but HTML 5 promises to change that
The Problem
One part of the interface that’s commonly forgotten in all this is the URL. Of course the WCAG give you some guidelines on how URLs should be formatted, but compared to web pages, that’s like only covering HTML and CSS and forgetting about scripting.
The URL is an important part of the user interface. Some people use it to identify what it is they are looking at. Some of those may even modify the URL as a shortcut to reaching a specific place on the website. The URL is also what all browsers use to create bookmarks and what some add-ons and plug-ins use to get information about what the user is looking at.
But for (very good) security reasons, you have little or no control over the URL from JavaScript, at least not without a round-trip to the server, reloadig the entire webpage. An example of a security reason is that a user should not be fooled into thinking they are looking at ‘paypal.com’ when they are actually looking at ‘iscamyou.net’.
Still, having no control over the URL means that the user is limited to bookmarking the page that they originally visited. Any changes you make to the page through JavaScript interaction won’t be reflected in the URL.
The Solution?
You could notify the server of change on the client using AJAX. But this will only work if the user returns using the same browser, or when they are logged in somehow. Since many people use multiple computers or browsers sharing bookmarks using applications like Xmarks, this doesn’t really work. It’s also no good if you want to share a bookmark with a friend, since the saved information won’t be available to them.
There is one part of a URL that you are allowed to modify using JavaScript, the hash. This the very last part of a URL: protocol://user:password@domain/path?query#hash. For example ‘#/two/four’ in http://grismar.net/hashjs/#/two/four. The problem with this approach is that the hash string is not sent to the server when the browser sends a request.
So, although you can save some information in the URL, allowing you to bookmark it and allowing plug-ins and add-ons to detect a change, it still won’t allow the server to determine what to send you.
The Clincher
The final piece her is to use JavaScript to read the hash right after loading the page and making needed updates (including getting any needed information from the server through AJAX) based on the hash.
Of course you should limit any information in the hash to changes you’re willing to limit to JavaScript-enabled users only. So, for anyone taking the WCAG seriously, this means cosmetic changes or changes in usability that simply require the use of JavaScript to work (animation, dynamic changes, etc.)
I ran into a good use case where I needed this when helping design a search interface for the Nationaal Archief (National Archives) of the Netherlands. Here, the need arose to search in many collections of information at once, while presenting the results in separate areas of the user interface. Some users prefer not to see specific collections and closing one of the results will allow more space for the rest of the results.
From a usability perspective, users might expect to ‘bookmark’ the state of the application as well as the query they had just run. But users also wanted to be able to change the configuration without having to reload the page after every change.
You can see a simplified example of that result here and just view the source (XHTML+CSS+JavaScript) and feel free to use it. The example uses jQuery, but of course this is not required to employ the technique. You can download a copy of jQuery from http://jquery.com.
