AJAX, JavaScript support and screen reader accessibility

Making websites and web based applications that use a lot of JavaScript accessible isn’t as easy as just making sure that there is a non-JavaScript fallback. Yes, you always need to make sure that your site degrades gracefully in user agents that do not support JavaScript. But that isn’t always enough.

One reason is how dynamic changes to page content are handled by screen readers. This has been a bit of an unknown area, but a couple of recent reports provide some answers. James Edwards, a.k.a. Brothercake, has done some research and written an article based on the results: AJAX and Screenreaders: When Can it Work?. The article shows that there are a lot of problems, and James comes to the following conclusion:

I’m forced to conclude that, unless a way can be found to notify screen readers of updated content, AJAX techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent non-script alternative being offered to users up-front.

James isn’t the only one who’s been taking a closer look at how screen readers handle dynamic changes to a page. Joe Clark has conducted user testing of Basecamp, asking ten screen reader users to accomplish three simple tasks in the application. Joe presented the results at Iceweb 2006, and an edited version of the speaking notes are available online in Build Half a Product: Is Ajax accessible? At all? The results show that while it isn’t entirely impossible for screen reader users to use Basecamp, it isn’t easy:

The conclusion I have from my testing is that Ajax has problems. Maybe not fatal problems, but problems nonetheless.

Bruce Lawson has more on the same subject: Ajax, accessibility and assistive technology.

If knowing that screen reader users are likely to have problems isn’t enough to make you worried, maybe reading about in-between scenarios such as the one Robert Nyman describes in An important lesson learned about AJAX and accessibility is. The scenario, which is probably not uncommon for large companies, is that JavaScript is supported and enabled in the web browser, but a proxy server removes certain scripts before they reach the browser. Since the browser has JavaScript enabled it won’t use any noscript content that you provide either.

The screen reader testing and the proxy scenario both clearly show that we need to keep in mind that JavaScript support isn’t just a question of yes or no.

Posted on May 18, 2006 in Accessibility, JavaScript

Comments

  1. I definitely agree that it’s not a simple yes|no answer to the question if JavaScript is supported, and I’m really grateful for everyone making all these tests.

    However, with productive environments compared to screen readers’ shortcomings in particular, I also believe there are business reasons behind the decision to sometimes be dependant on JavaScript, reasons that sometimes economically outweigh being able to guarantee a perfect end user experience in a screen reader.

    Please don’t get me wrong, I am of the opinion that the content/information should be accessible for everyone, but at the same time, I find cases for people building application-like web sites where it is, in my humble opinion, ok to have a demand for JavaScript (think of web sites simulating a web operating system).

    Naturally, every web site should be built on a solid foundation and with progressive enhancement, but at the same time we need to be aware that there is no decent way in certain scenarios to give everyone the exact same experience.

  2. May 18, 2006 by Ajaxlover

    Hmm I thought AJAX was a swedish band?

    http://www.svenskadansband.se/img223.htm

  3. This is always a big issue in my opinion. Mostly i test sites with the lynx browser, right of my server. If i can can browse trought lynx, i asume that screenreaders also can browse it. I’m in doubt wether i give 88% of the users a better experiance trough JavaScript and XML, or to make it 100% accesible with the note on the 12% which are somehow impared. I work mainly with PHP and my experiance with Ajax is that you can’t do things in PHP which you can with ajax. The only thing i can think of is to check if javascript is enabled and present seccondary content to them. Any other ideas? because i’m aware of the fact that most sites i make will not stand the “silver bullet” test.

  4. Good pointers, however I would argue that applications - or web-applications to be precise - as basecamp most likey never were buid for screen readers, and probably never will unlsess it becomes a huge economical success doing so. One could argue that they are missing a large piece of the marked, I don’t really know, but I have a feeling that the time it takes to develope the alternate version of basecamp probably wouldn’t match the possible extra income (not to say keeping the alternate version up to date aswell as new features comes along). Also, and most importantly - I would guess that the developers would find the stripped down version not having the look and feel they are trying to sell, infact the AJAX and javascript features are what makes many of the tools so efficient and cool. I could be wrong however!

    Google mail aswell. Such a program could “easily” (given google has a few thousand developers lying around) work without javascript, however it would not be as cool and featurerich - therefore it’s not the same tool anymore in some way. However I feel I’m going the wrong way now…

    When it comes to accessible AJA(X/H), I would most definately agree that builing them accessible isn’t only impossible at times - but it usually ends up with building two sollutions so it’s very time consuming. In a project where a customer is paying for the work, it usually boils down to if the customer are willing to pay for the extra efforts developing a system “nobody” sees. (i write “nobody” to make a point, we all now that quite a few could fall into the category)

    As a business rule, atleast in my case, I would say that frontend design should be accessible with fallback while a backend doesn’t require it, it requires customers with javascript turned on.

  5. @Kim: Google Mail does have an HTML only feature. You may not have noticed it… the link is at the bottom when you are logged in. The HTML only version isn’t slick, but it is available. There’s no reason not to have it, considering that many users want to access their mail in locations where Javascript support is unavailable.

  6. Is it not more interesting to develop bookmarklets, eg FF extensions to accomodate these accessibility issues? It would be great that the specific target audience of eg screen readers could be told to use that extension and voila provide all websites with that functionality. Is it possible?

  7. @Kim

    ”..In a project where a customer is paying for the work, it usually boils down to if the customer are willing to pay for the extra efforts developing a system “nobody” sees…”

    I agree. This is the most common issue in many cases. I would like to build better solutions but it really boils down to the available time, and budget for a project.

  8. @Christian Montoya: Well there might not be a reason for not supporting all and every user on the planet, but one could also argue that the the technology for example screenreaders is not sufficient for web2.0 applications (Since AJAX has become such a web2.0 buzz word i generalize and say web2.0).

    As you also point out the javascript-free version is by far as feature rich, it’s purely a basic service.

    Is it really to expect that a web2.0 applications should work on lynx as a worst case scenario? Note I’m talking of larger applications, not on single functions like tip a friend or popup windows - theese should always be accessible.

    @johan: I agree with you, I think that it is up to the browser to support the technology needed to ensure a great user experience. Web-applications has been taken to the next level, and I wonder if one really could expect a service to work without javascript? (Again, the example in mind was systems like gmail and basecamp, not onoff.se which is a webside for random users)

  9. @Kim

    i have an app that autofills location of the persons town. Based on Ajax and the Sajax lib. This is only possible trough Ajax in PHP.

    example: jungsonnstudios.com/sajax/nl_plaats.php (in dutch)

    This is a rich feature in which i needed to use Ajax. If you type in a letter it will search a database through 3000 locations in my country.

    I have not found a better way to do this. If any one can do it otherwise i like to know about it.

  10. May 19, 2006 by Jon Gunderson

    There is work being done on making AJAX and DHTML application more accessible at the W3C and Firefox.

    Dynamic Accessible Web Content Roadmap

    Accessible DHTML with Firefox 1.5

  11. I think it was about time the screenreader manufacturers pulled their fingers out - they seem to be ignoring new technologies, and more importantly, seem to be ignorting standards and semantics.

    A lot of our effort goes to waste because accessibility tool manufacturers don’t make enough effort to take advantage of web standards.

  12. May 25, 2006 by jbot

    The simple answer is to create your applications to work without any JS/AJAX/DHTML in the first place, and then add it later as behavioural layer. I don’t see any reason that - if a project is properly specced, planned and documented - it cannot be done without a large production overhead. It’s all in the planning, after all: fail to plan, plan to fail.

  13. @jbot

    I agree this should be planned in the first place. But sometimes it can add value to the site and the users experiance, and in some cases it really is, but first look for a solution beyond scripting is always a good idea.

  14. I suppose the core issue here is that screenreaders were developed without the idea of a modifiable DOM.

    That said, I’ve been toying with the idea of #fragment links. Let’s say you have a position:fixed DHTML “popup” (in-page) notification that has an id of “messagepop” and is aligned to the top edge of the browser viewport, and then you set the location to #messagepop. Would the screenreader then read out the text of the in-page popup?

    Another issue would be returning the focus back to the original location from before the interruption. Might history.back() work? If so, we might have a solution!

  15. Bah, I just finished reading that Sitepoint article, and my little technique is discussed there. Like the others, it has different effects with different accessibility assistants.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.