Accessibility / Section 508 with Ajax / Atlas

Wallace B. McClure – When people talk about Accessibility, I think of Section 508 and allowing blind/disabled people to use an application. I put this small test of Atlas together for a blind friend of mine to test. It is located here. It seems that the applications runs find and he is able to see/hear the content using JAWS ( So, the question is, what’s the cause of the accessibility discussion with Atlas? What are the issues?   I hear discussion but not statement of the issues. Any information that you can provide would be appreciated.

Many people cry out “Accessible Ajax? Impossible!”, but how many have actually tried things out with JAWS and the like, and seen what works and what doesn’t?


Comments feed TrackBack URI

Comment by Chris — January 3, 2006
My hunch (and it is just that, a hunch) is that not only is assistive technology unfamiliar to mainstream web developers, it is also difficult to obtain and, perhaps most importantly, the web experience of users who need this technology is totally foreign.In the US Federal government sector (and I assume the educational sector as well), 508 compliance is a must, and the easiest, cheapest way to ensure it is to develop to the known lowest common denominator. Even at that, people still don’t get it because the user experience is foreign.Patterns of how to gracefully degrade AJAX to non-AJAX interactions are not readily available, either, I believe. Having access to patterns demonstrating graceful degredation might help promote the technology.
Comment by Michael J. — January 3, 2006
If I understand correctly, there are two major “standards” regarding accessibility: the Web Accessibility Initiative guidelines and Section 508 standard. According to WAI guidelines application should function with Javascript turned off. Easy to understand, simple to test.The Section 508 allows JavaScript and does not require website to function with Javascript turned off. In requires that information should be “accessible” with some kind of assistive technology. This sounds kind of cumbersome, so there is no wonder web designers oftet pass on it.Ajaxified input elements are not WAI complaint, because they require Javascript to be enabled for various onClick or onChange events to work. On contrary, a whole ajaxified form can be made WAI compliant if ajax function is hooked to onSubmit event. If Javascript is turned off, the form is submitted synchronously. If Javascript is turned on and XHR is available, the form is submitted asynchronously and content of the form is replaced in-place. Call it AJAX, AHAH, IPU or whatever else, but it works. Yes, it is not as fine-grained as suggest-type controls, but it still saves on full page refresh in modern browsers while keeping compatibility with older browsers or Javacript-disabled systems.I started a project to implement such coarse-grained dual-mode (Ajax and non-Ajax) components. Seems to have worked out quite nicely. Please see for implementation of In-Place Update technique that appears to be WAI-compatible.   

Comment by Shawn — January 3, 2006
I haven’t looked into the functionality in a while, so feel free to correct me on this…From what I understand, screenreaders work fairly well with JavaScript, but last I knew they would start reading from the very top of the page whenever new content appears anywhere in the page. So something along the lines of find-as-you-type would get very annoying, very fast. Hoping that the writers of screenreaders have started realizing that they only need to read the containers that have changed and not the whole page…Done right, accessible AJAX should happen just as easily as accessible markup. Do things in a certain frame of mind and you get accessibility for free. Not to mention having all of the functionality in one place, as opposed to hooked directly into all sorts of markup. BIG maintainability bonus there…
Comment by Chris — January 3, 2006
The question of degredation is still valid, though. There are parts of the US Federal Government that still use Netscape 4.1 precisely because it has so few “modern” functions and can be easily (so they say) locked down.It is interesting to watch this progress, though. When CSS first burst on the scene there was a lot of conversation about how to accommodate the different quirks of browsers. Now, with accessibility, it is about how to accommodate the quirks of browsers and assistive technology. CSS got sorted out and is run of the mill now. Hopefully this will be, too.
Comment by RichB — January 3, 2006
A lot of the links on GMail are not HTML anchors, they are spans with an underlined decoration, a hand cursor and a blue color! I suspect these come out differently for JAWS and tabbing through the hyperlink list.
Comment by Wallym — January 4, 2006
Thanks for all the info folks. This is good stuff. :-)Wally
Comment by Kevin — January 4, 2006
Alot depends on how you define AJAX as well. See “4 Quantum States of AJAX” @ If you’re heavy on the DHTML side of AJAX, not just the simple async-communications as in the example provided, then screen readers become progressively more challenged. I’ve actually found Windows Narrator (MSFT’s built-in screen reader) to work better with DHTML than JAWS historically, but then again there’s a new release of JAWS out that I’ve admittedly not explored yet.
Comment by Aaron Leventhal — January 5, 2006
Accessible AJAX/DHTML/JS is a huge new area which is being worked into a W3C standard. This allows you to make complex key navigable widgets such as spreadsheets and menubars out of divs, in a way that is accessible with assistive technologies.An implementaion of it already exists in Firefox 🙂 You need to use Window-Eyes 5.5 (best support currently) or JAWS 7.x (catching up).Please take some time and see for documentation and samples (spreadsheets, menubars, tree views, alerts, progressbars, etc.). Basically you’ll need to properly design the keyboard accessible and then mark up the role and property attributes of each div/span element.This technology is backwards compatible with XHTML and can be used with HTML as well.   

Comment by Rich Schwerdtfeger — January 5, 2006
To add to Aaron’s previous comment, Accessible AJAX/DHTML/JS is being backed by new W3C standards work, called the Dynamic Web Accessibility Effort, found at Not only are we addressing scripted web content but we go on to do some web reform. For example accessibility issues like using tables for layout can be indicated through the additional role attribute for presentational. These standards are also cross-cutting and may be applied to other markup like SVG. For a better understanding of the problem and how it is being addressed please refer to the Dynamic Web Access Roadmap at
Pingback by Bien batido y revuelto » Usabilidad para todos — January 8, 2006
[…] Y siguiendo con el tema, un tipo hizo una prueba con un amigo ciego sobre si una aplicación Atlas es accesible, utilizando JAWS como ayuda de navegación. La prueba es informal y los resultados dicen ajustarse a la section 508, pero en los comentarios hay reflexiones bastante interesantes. […]

Ajaxian » Accessibility / Section 508 with Ajax/Atlas

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: