AJAX and Accessibility
Recently, there has been a lot of interest in using AJAX (the technology, not the detergent) when building web applications. I have a feeling that javascript and the XMLHttpRequest object will be the Next Big Thing ™. Let’s have a look at how usability and accessibility of AJAX forms can be improved.
In this article we will have a look at the implications for accessibility and usability when using Javascript to dynamically update a web page. I will also show how you can increase accessibility for AJAX-based forms.
This article is also available in Japanese and in german.
For those who haven’t heard of AJAX before, I recommend you head over to Jesse James Garrett’s article “Ajax: A New Approach to Web Applications” for a good introduction. If you want more information on how to create your own AJAX forms, see the references section at the end of this article. If you can’t be bothered to read that, here is the outline: There are two ways of dealing with forms when working with web applications:
- Update the entire screen when the user clicks the submit button. Data is posted to the server, analyzed and depending on the business logic the user is redirected to a new page or the same page is rendered again. Let’s call this traditional forms.
- Use javascript to call the server with form data, parse the result in javascript and update only the necessary parts using the DOM. We’ll call this AJAX forms.
What are the advantages?
There are many advantages in using the AJAX forms. It is possible to create a more advanced user interface that doesn’t refresh the page for every change made by the user. For complex forms usability can be improved as it is possible to make updates as the user moves through the form. An example could be to validate complex form field data or make server side calculations as the user leaves a field.
Many inexperienced web users have difficulties understanding the traditional way of posting form data. Especially in situations where pressing the back button after submitting a form makes the browser display a warning message about form data being resubmitted.
What’s the problem with AJAX?
Using AJAX forms require more from the client compared to traditional forms:
- Javascript has to be enabled. This rules out some browsing devices such as certain mobile terminals and Lynx.
- The browser has to support the XMLHttpRequest object (or similar). Currently this is available in Mozilla, Firefox, Internet Explorer and Safari. Rumour has it that Opera will introduce it soon.
These requirements should not pose a problem for most applications. A lot of web applications are developed for a particular organisation where the client environment typically is very standardised.
But, there are some other problems regarding accessibility. Consider this simple AJAX calculator. Screen reader users have no problem using the form. But when they click the “Add” button they will not know that the result value has been updated. This, obviously, is a major problem.
Even sighted users may have difficulties understanding what area of the page was updated. Miniscule changes are hard to detect on screen, especially if you are looking at the keyboard while typing (I still do).
Does this mean you shouldn’t use AJAX for your web UI?
Improving accessibility of AJAX forms
Fortunately there are some things we can do to increase accessbility of AJAX forms. Here are my recommendations:
- Inform the user at the top of the form that it requires javascript or detect javascript automatically and warn the user when it isn’t available. If the form has many fields you will spare your users a lot of frustration. Everyone hates filling out a form just to find out that they can’t submit it.
- Inform the user that the page is updated dynamically. This is especially important for screen reader users and will help them decide when to trigger a re-read of the page.
- Make it possible to recieve an alert when information was updated. This may not be practically possible depending on the complexity of your form but will help a screen reader user a lot. Alert boxes are read by the screen reader and are usually displayed together with a sound. The checkbox should be displayed so it is clear that it is not part of the original form.
- Highlight recently updated areas for a short period of time. This will help sighted users understand what just happened. The nice folks over at 37signals have dubbed this “The Yellow Fade Technique” but you can use any colour you like. Check out Adam Michela’s code for another way of providing the fade.
Let’s have a look at the accessible AJAX calculator to see these recommendations in action. Compare it with the first version of the calculator. A decent improvement with relatively little effort.
I hope this article will inspire you to make sure your AJAX forms are accessible.
References:
- Ajax: A New Approach to Web Applications by Jesse James Garrett
- The Yellow Fade Technique by Matthew Linderman
- The Fade Anything Technique (FAT) by Adam Michela
- Using the XML HTTP Request object by Jim Ley
- Dynamic HTML and XML: The XMLHttpRequest Object
In your example the yellow fade is over far too quickly, I remember the basecamp one to last a bit longer.
I think that displaying the yellow fade and the alert is confusing, in fact I thought the yellow fade would be the alert.
Anyway, interesting article which im sure will be a good source of reference and debate.
Tom, thank you for your comment. The timing of the yellow fade should be researched further.
The idea is that the alert only should be switched on by those who need it. Default it should be “off”. If it isn’t there it will be very difficult for a screen reader user to understand when the result is updated.
The Opera 8 betas already has support for XMLHTTPRequest, so it’s more than a rumour.
What the heck is “Ajax”? It’s always been called RPC (remote procedure calls) or “remote scripting” for as many years as I can remember by anyone who actually uses it.
A- asynchronous not needed x- xml/xhtml/xslt/xmlhttprequest not needed, often very undesirable
Ja?
>The browser has to support the XMLHttpRequest object
-no, it’s not needed. There are about 5 different ways to do RPC and I wouldn’t even use XMLHttpRequest for IE for simple GETs because of security setting problems; rather dynamic scripts.
Stylo, I did not coin the term “Ajax”. If you haven’t heard about it before I suggest you check out “Defining Ajax”.
“no, it’s not needed” -Yes it is if we are talking about Ajax. If you talk about RPC in general it isn’t.
The reason I named the article “Ajax and accessibility” is because Ajax is becoming more widely used and has become a buzzword. My suggestions above apply to other RPC methods as well.
>has become a buzzword
Only amongst marketers and blogger sheep – excuse me, people – who read them, not people who actually invented and use RPC. “Ajax” is a terrible, incorrect name for the reasons noted.
>using Javascript to dynamically update a web page -sure, of course you need XMLHttpRequest if using XMLHttpRequest, but you don’t need it to fetch data from the server with js, which was your – and my – greater point.
I’m not convinced about the accessibility solution; what it basically comes down to is, use alert() to identify every change.
But surely, an application based on continual alert() dialogues would be incredibly annoying to use? A simple calculator with a single output, maybe not; but what about a complex form where many values change at once – do you do multiple alerts (even more annoying) or a single alert with lots of data (a big chunk of text with no semantics – difficult to comprehend)
As interesting as this technology is, I’m extremely reluctant to use it without a better way of catering to script-capable screenreaders.
Here is a better fade. I call it the Fade Anything Technique (FAT).
Just a note regarding “warning about JavaScript”. This is fundamentally flawed because the application SHOULD still work without JavaScript. Maybe not as elegantly, but it should work. All critical tasks/functions should be able to be performed without JavaScript. 2cents.
This article was a good read. Thanks :)
brothercake, I am not convinced either. Wether to use alert popups or not should be a decision by the user. Default should be “off”. But for a screen reader user I have not yet found a solution that works for large forms. Alerts are usually read by the screen reader.
Adam, great code. I put a link to your post in the references section.
AJAX stands for Asynchronous Javascript and XML
Stylo is right – this whole “AJAX” thing is the result of a web consultancy (Adaptive Path) looking for new ways to market themselves, and thus they coin a term that essentially describes what’s been possible to do with DHTML for years now.
There’s nothing “new” here.
Joe, this article isn’t primarily about AJAX. But I choose to write about AJAX to help developers who are getting started in RPC. Call it a buzzword or whatever you like but my aim is to make it easy for new developers to find information about AJAX and accessibility.
I’m with ya Pete.
You guys really need to stop whining about the term Ajax.
It is a widely recognized term. People use it because it’s easy to use… nobody cares EXACTLY what it means.
Let’s get on with it and stop all the foot stomping.
“Blogging” is nothing new either, but that didn’t stop the nextgen web developers from thinking they created a new thing either. Easier to roll with the punches than whine about terminology, I guess.
I don’t think the alert was a single bit of help in your “accessible AJAX calculator”. In fact I think combined with the flashing answer section, it was a bit excessive.
I honestly think the best way to do to approach this issue is to follow the form of a normal application interface, one where the result update happens in the area expected. The problem with the example you provided is while being a calculator, it looks nothing like what we think of when we think calculator.
I believe this is something gmail did successfully. The layout of google mail is (while also similar to a traditional web mail) much like that of any MUA. We know what to expect.
The same could be approach could be used by making your calculator *look* like a calculator. Even if you wanted an additional background colour change to notify the user of the change, it would be sufficient.
I am quite excited about Ajax, I think it might cause us to finally see more well written code in ECMA. ECMA (Javascript) has been thuroughly abused by web designers giving the language itself a bad rep. Honestly, its quite a nice little language. Attractive, simple, dynamically typed. Hopefully now we will see more clean ECMA code in the real world.
Scott, I think you may have missed the point of my article. This article is about the accessibility implications of using AJAX, not about calculators or AJAX itself.
Maybe not for you. But which screen readers do you know of that informs users about the result being updated? Just updating the result dynamically isn’t good enough.
My example is not meant to be a full calculator. It just performs a simple operation on the server side. If you make the calculator look like a calculator you may help sighted users with regard to usability. How do you make it “look” like a calculator for users who can not see?
Gmail’s interface is a poor example with regard to accessibility. The non-standard HTML is generated from javascript and is useless for anyone without proper eyesight.
What about changing the cursor when the server is working ? For example a ‘wait’ cursor.
I’ve just translated the article into german:
AJAX und Zugänglichkeit
Why wasn’t this first issue to address the reliance on Javascript being enabled?
I think the biggest problem is people are treating AJAX as a replacement for your traditional POSTed form, which it most certainly is not. AJAX is supposed to enhance the experience, not break the form for a given audience.
If you’re building your form from the beginning with a reliance on AJAX, you’re already headed in the wrong direction.
That’s not to say this example was bad, there are many different issues to address with regards to accessibility. This article helped make some of the “not-so-obvious” issues more apparent.
Justin, you’re correct about the reliance on Javascript. There’s the concept of progressive enhancement that I think we should all consider when it comes to using AJAX.
In many cases it’s possible to create fallbacks for AJAX – form will just require full roundtrip to server.
When you want to extend forms – take a look at WHATWG Web Forms 2.0.
BTW: example calculator works in Opera8, despite what warnings say.
Justin: Couldn’t have said it better myself!
i hope i figured out everything right:
would have been good if you added fallback already into example 2. i’m using elinks oftenly when “beeing remote” and so right now trapped into it, because “add” is not accessible at all.
what if your form is longer then window and the changed and therefor higlighted field is out of view?
when talking about accessibilty you have to remind colorblindness and contrast and page zoom when doing those color sweeps.
someone proofed ajax for multiuser issues and/or pushing data from server?
i’m ready to escalate when chieftain or customers will begin asking for those things.
My tutorial on creating an accessible javascript app with progressive enhancement: http://ajaxredux.com/feature/progressive_enhancement_tutorial.php
Rich,
We have a question for you: Do assistive readers read the html behind the page or the DOM?
ie. If I have a empty DIV tag on load. The user clicks a button and on the client we insert text into the DIV tag and then set focus on that DIV tag, will the reader then pickup that text.
I could not get JAWS to read the items in that list – it would only read the first item “Item 1 vanilla 1 out of 6″
I think you are looking at the problem from the wrong way around wrt screen readers. What we need is a screen reader with Ajax support.
Steve, from what I understand, JAWS works on top of the Internet Explorer DOM. However, it tries to create a representation of the page similar to what it looks like on screen. As such it will not read text in elements with display:hidden or visibility:none. On top of that it will only make one pass at reading the page.
Dynamically changing elements will therefore not trigger a re-read of the page (the user has to trigger a re-read manually).
Douglas: Changing how screen readers work is a matter for screen reader developers (and it could take years). Until they change their products we have to come up with a solution.
Who really cares about disabled people anyway? If people really cared about disabled people, they would give up some of their precious time to sit down and help them browse the web, talk to them about their lives, and, simply put, just be friends to those less fortunate individuals.
However, it seems this “solution” is just far too complicated. Since our humanity has obviously failed us, why not replace it with technology? After all, it’s far better to create a system that allows us to separate ourselves from those rejects. This way we can shove them into the nearest closet, stick a computer in there, and finally get on with the more important things in life (whatever those might be)!
This will also free up more time to pretend to feel sorry for the guy coasting down the sidewalk in a wheelchair, which is really just another way of saying, “Gee, glad I’m not as useless as that guy…”
Plus, we can use the extra energy to cast glances of horror at strangers with facial disfigurements and/or deformed bodies.
Somebody said “I think we are looking at the problem from the wrong way around” but it probably would’ve been more accurate to say “We are not looking at the problem at all.”
Denny, it seems like you are extrapolating heavily from my article about AJAX and accessibility.
The disabled people I know have been pampered since childhood and absolutely hate having someone “sit down and help them browse the web”. They would rather like to be able to do it on their own without the help from someone else, just like everybody else.
This where technology can help. A lot of disabled people have access to the massive information on the internet only to find it mangled by poor writing, poor design, and crappy markup created by developers. I am trying to do my part to fix the latter.
I can’t understand why you fail to combine this with “being friends to those less fortunate individuals”. Are you having a bad hair day?
about the name AJAX, it is different from RPC. RPC, by its now common definition, is what XML-RPC and SOAP uses, among others, for just that — remote procedure calls. you aren’t always using a RPC for an AJAX script. RPCs (by the now standard definition) use an XML envelope to send a request and an XML envelope to receive a request, while AJAX sends an HTTP GET request (which can hardly be called RPC anymore) and gets back XML data (not in an envelope) to parse the data and play with however it wants. it really is a newer idea, just all bundled into one nice idea framework, AJAX. also, the fact that the javascript and the web server don’t have to wrap the communications in an envelope makes it a lot speedier than an RPC. imagine google maps if your browser running on an old PC had to generate an XML RPC request, send it to the server, google’s server had to unwrap it, parse it, and wrap a response, then when you get it back, your browser has to unwrap it then parse it. that’d be highly inefficient when an HTTP GET request is much faster and easier.
as for the accessibility, i found this article by doing a google search for “ajax accessibility” because i like the concept, but i did think about what it would pose to blind users with screen readers. i work for a state government office, and with all the web apps we write, everything has to be section 508 compliant, as well as working with any screen reader. we thought about using ajax for some more dynamic apps, but then i realized that the page doesn’t refresh, which helps the screenreader. so thanks for this article, great job!
I believe that Accessible is a more wide word then think-about-blind-peoples, this is only part of the issue. Tim Berners-Lee said: “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” When we project a website or a RIA, we should pay attention to this fundamental concept. There are disadvanced peoples that have some limitations: physical or cognitive disability, obsolete hardware, old software, little common systems or configuration, low speed connection, etc.. Accessibility is a noble intention, but also means open our website to a more wide slice of costumers (people that can’t access to our products, doesn’t use/buy them). Think to access growth to internet from country likes India and China, they have low speed connections, old hardware with open source software. They will represent soon the future of web-surfer, and they can’t access to your contents. We know that build an universal website is impossible, but we have some standard compliant tools and methods that give us the possibility to be near to our goals. I think that AJAX actually bring us far from universality of web. New technologies must enhance usability, not decrease it!!
I’ve known AJAX about a month ago and i said: “Wow!! This is the future of web”. So, i’ve read a lot of documentation and searched existing code library, but I think that this model development have some limitations / problems.
Of course this is only a fast overview of the problems, but represents big limitations to accessibility. I think that the use of AJAX is dangerous, we can use it, but with care.
For a really easy color fade technique, please visit: Introduction to Javascript Animation, color fades and resizing Hope you like it, I have programmed it so it is very easy to use, and the functions can be used to animate any CSS property which uses numbers.
Does this mean Adaptive Path is anti-Flash?
What kinds of applications is Ajax best suited for?
i’ve been a lurker for quite some time and i love your site. great article, it’s the best that i’ve read about how web accessible is AJAX. thanks!
Michelle, thank you for your kind words.
jeff_we34: I am not quite sure what you are looking for with your questions. I suggest doing a Google search for more information.
Regarding Luca (comment #34) and search engine placement, there is an article at AJAX and SEO that offers a few ideas about indexing content within an AJAX application.
Hi Pete,
My hope is that my new concept, ASK, shall address these issues and at the same time help people to easily implement an accessible approach:
ASK – AJAX resource kit
Accessible DHTML is being designed at S3C to address these sorts of issues. In fact I’ve been saying we should call it AJAX accessibility because people don’t realize it applies. Currently Firefox implements it. There are things like accessible alerts which allow the author to have text spoken as soon as it changes or appears. We have accessible custom controls like spreadsheets, menubars, tree views and tab panels, which work like their desktop counterparts.
I invite you to take a look at http://www.mozilla.org/access/dhtml
Perhaps the most important aspect of accessibility is that it must work without javascript or any of the other fancy functionality. Your calculator didn’t work for me because I don’t use javascript – it would have been easy to make it work. It would also mean that those with accessibility problems could bypass the disadvantages of ‘AJAX’ by disabling javascript to use the ‘fall-back’ standard behaviour.