Tuesday, January 3rd, 2006

Accessibility / Section 508 with Ajax/Atlas

Category: Accessibility

Over on the .Net side, Wally is talking about Accessibility / Section 508 with Ajax/Atlas

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 (www.freedomscientific.com). 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?

Accessible Atlas

Posted by Dion Almaer at 11:19 am

3.7 rating from 14 votes


Comments feed TrackBack URI

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 Chris — 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 http://jspcontrols.sourceforge.net for implementation of In-Place Update technique that appears to be WAI-compatible.

Comment by Michael J. — 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 Shawn — 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 Chris — 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 RichB — January 3, 2006

Thanks for all the info folks. This is good stuff. :-)


Comment by Wallym — January 4, 2006

Alot depends on how you define AJAX as well. See “4 Quantum States of AJAX” @ http://ajaxian.com/archives/the-four-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 Kevin — January 4, 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 http://www.mozilla.org/access/dhtml 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 Aaron Leventhal — 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 http://www.w3.org/WAI/PF/. 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 http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap110505.html.

Comment by Rich Schwerdtfeger — January 5, 2006

[…] Comments feed TrackBack URI […]

Pingback by EnableAccess » Blog Archive » Accessibility / Section 508 with Ajax/AtlasCategory — January 11, 2006

Having just begun learning a little Ajax for a site i’m building at work I decided to check for myself how well my ajax code, and the code of others, works with Jaws 6.0 – which my wife, who is blind, uses.

It seems to me, in my very limited experience and from my very limited testing, that the technology itself isn’t causing much in the way of problems for the screenreader (i’m sure there are some issues, but I haven’t encountered them yet – and other screenreaders?). What I think, imho, will be a much bigger issue is the age-old question of how to make the page accessible in general. In other words, it’s not so much that the content was dynamically generated, it’s how the content is navigated to. the oversights many developers will likely make will be in forgetting very basic things about accessible design; for example: the fact that blind users, among others, don’t use a mouse and so triggering an ajax function with ‘onMouseOver’ makes the content behind that action inaccessible. and Ajax, since it makes navigating the page more complicated by adding more navigation options, amplifies the old problems.

Comment by Jeremy C — January 29, 2006

So… DOM manipulation in general.. breaks the WAI guidelines??

Thing is… to a company.. what is more imporant? Catering for the majority and providing them the best user experience possible (and therefore.. generating the most sales possible)… or catering for minorities and letting development time become several times of what it would be otherwise?

Is not-considering-a-group acutally discrimination or just… not being flexible enough to cater for them at that stage? Especially in a market that is becoming over-crowded.

Surely… development can go two ways… One that caters for accessibility and the other that is more concerned with wowing customers and getting contracts.

Comment by Tim Leonard — March 16, 2006

As a designer who’s worked on meeting section 508, I’m very interested in this issue. From my experience, script driven navigation causes problems with meeting the section 508 requirements (even as simple as javascript:history.go). I have not yet ventured into AJAX, so I’m very interested to hear what you all say. As for WAI — Don’t necessary assume that catering to accessibility and getting contracts are mutually exclusive. I am personally aware of an instance where a huge UK contract could not happen due to a Web based application not meeting WAI-AA. Bear in mind:
1) The baby-boomers are retiring.
2) Recent studies show that people with disabilities actually use the internet more than the non-disabled.
3) More and more, basic services are moving to the Web (licences, banking, paying bills, traveling, medical care).
Allowing every day “life administation” to move online without accounting for disabilities would be like suddenly removing all HP access ramps, nation wide. It’s not a small issue.

Comment by Jim Griesemer — March 30, 2006

AJAX and Section 508 Compliance

Trackback by Matthew Podwysocki's Blog — May 17, 2006

[…] An interesting discussion here. […]

Pingback by Knowledge Notebook» Blog Archive » AJAX™ and 508 compliance — July 28, 2006


It was quite useful reading, found some interesting details about this topic. Thanks.

Trackback by Accounting Jobs — November 23, 2006

Keep in mind that Section 508 does not equate to programming a web page for screen readers. Screen Readers evolve and morph over time. The Section 508 requirements are simlar to, but still different from the W3C’s accessibility guidelines.

Comment by Eric Crone — February 5, 2007

Leave a comment

You must be logged in to post a comment.