Improving accessibility for today’s AJAX - To hack or not?
This posting ends up being like previous quiz questions, but I’m dropping the old numbering sheme (related to WCAG principles) and the multiple choice answers as well. New year, new topics, time to move on.
I want to ask about a proposed technique, but first the set up.
A short while ago, Gez Lemon and Steve Faulkner published a very good article about how screen readers behave and some ideas on Making Ajax Work with Screen Readers. If you haven’t read it yet, it’s well worth the read. … Now, I’ll wait.
So, they’re back again with another. This time, they’re trying to lessen the burden on the visitors who use screen readers. Why put the onus on them to constantly shift modes if there’s something programatic that can be done? In Improving Ajax applications for JAWS users, Gez and Steve reveal a technique they have found which forces JAWS 7.1 to update its virtual buffer without user intervention.
I should trust that they are right in saying it’s new to JAWS and probably does little for other assistive technology products. Yet, as much trust and resect I have for these guys, you never know when a JAWS competitor might implement the same trigger. Plus, I’m curious to actually try it with a variety of assistive technology and browsers, more than I have at my own disposal.
That’s where you come in. I have two very simple test cases for you to try. The first is as simple an AJAX application as one can write. (Actually, I liberated it from Brothercake’s Sitepoint article AJAX and Screenreaders: When can it work?) The test case has one link which does one AJAX call and updates a paragraph. You can’t make one any simpler. The second test case simply extends the first with Gez and Steve’s updateBuffer technique. Go give each of them a quick try with whatever array of assistive technologies and browsers you have. Tell us how they behave.
April 25th, 2008 at 11:57 am
I often work on web sites and web applications. I am not visually-impaired and do not personally know any visually-impaired people, but I am interested in making my web pages accessible to those who are. And although there is much lip service paid to accessibility, there are very few tools to truly test whether a page is accessible.
Anyone who develops web sites knows that the only way to tell whether their code does what they intend it to do is to actually fire up their browser and look at the site. So, although I hear about the best practices for making web sites accessible (such as having “alt” attributes in image tags), I feel that I really have no idea how accessible my sites are because I cannot afford to test them with the expensive auditory browsers made for the hearing-impaired.
I do not want to actually listen to the audio because that would take too much time. I do not want something as complex or full-feature as an actual auditory browser. I simply want a text readout of what the audio would be. I thought that the people who make JAWS, which seems to be the most popular auditory browser, might have a free program for developers to test their sites against JAWS. It is, of course, in their best interests to make sure that as many sites as possible work well with their product. But I have contacted them and they have no such program. They suggested that I buy simply buy the expensive JAWS product if I wanted to do testing. I’m sorry, but no.
After searching the web for other programs to simulate the auditory browser experience, the only thing I could find was a Firefox extension called Fangs. But although it is nicely written and is much better than nothing, the lastest version was released in 2006 and is pretty minimalistic.
So I am wondering: what am I missing here? How can it be that almost noone thinks its a good idea to verify a site’s accessiblity by actually testing its accessibility? Perhaps I am crazy, perhaps the world is crazy, or perhaps it just doesn’t care. Or, maybe there is a program out there that does what I’m asking. Any suggestions?
May 5th, 2008 at 7:01 am
Tom, Yes, actually testing accessibility is the best proof, and organizations that are seriously interested in accessibility do just that. They test , using the same tools their users with disabilities will be using (no one seriously impaired uses Fangs) and often using real people with disabilities to test. There’s no better way. The automated test tools are getting better, but still miss al lot, or misinterpret a lot.
Once you begin to understand how a blind person uses a computer, you will find that testing with real screen readers, and using them as the blind person uses them, to be very efficient. No one sits down with a print out or text transcript as a testing technique. They fire up the tools and listen. With a little practice, you can learn to listen at 350 words per minute and use all of the shortcut keys adroitly enough to test the features you build into an application.
Yes, the tools are expensive; they serve a very small audience and are incredibly costly to keep catching up with new technologies. Yet, they are what the People with Disabilities depend on, and they are the tools that should be used for testing.
If you’re serious about accessibility, and your business needs to affirm the accessibility of your products(*), the tools and actual testing are a small and worthwhile investment.
Then, after you understand how a blind person uses a computer, and uses the assistive technology tools, put your hands behind your back and start using a mouth stick or a head stick as your only input method. After that, put on some ear defenders and try finding text alternatives for all of the audio material you might come across.
Actual testing is the only good way of assuring accessibility, and if you are really interested, you’ll invest in the tools and take the time to learn how to use them exactly as the people who depend on them.
* Businesses who sell their products to any part of the U.S. Government are required to affirm the accessibility of those products (how they comply with “Section 508″) by completion of a “Voluntary Product Accessibility Test” report (VPAT). The VPAT is a legal document that must be accurate.