WCAG 1 and AJAX Re: Can AJAX find harmony...

On Mon, 17 Jul 2006 17:51:20 +0200, Bailey, Bruce <Bruce.Bailey@ed.gov>  
wrote:

> WCAG 1.0 deals with AJAX quite neatly (but harshly) via Level Checkpoint  
> 6.3.  Of course, the article was not discussing the WCAG 1.0 definition  
> of accessibility, and applying WCAG 1.0 to AJAX is not really a very  
> interesting problem.
>
>> Also even many sighted users may be looking at the keyboard as they
>> type and not realize that AJAX has refreshed a part of the screen.
>
> Thinking about the current WCAG 2.0 draft and AJAX, however, is *very*  
> timely.  Does anyone here believe (to closely paraphrase from the  
> article) that accessibility is impossible for Web sites that use real  
> AJAX?

I don't believe that "accessibility is impossible for Web sites that use  
real AJAX". I don't even believe that WCAG 1.0 conformance is impossible.  
And having spent a while working in the mobile web, I think that WCAG 1.0  
conformance is in fact desirable for AJAX beyond just the accessibility  
market.

What WCAG 1 says, basically, is that you should be able to use a service  
without relying on client-side scripting. In no way does that forbid  
client-side scripting, which can be very useful. It just requires that  
where it is not supported, you provide some equivalent functionality  
through server-side processing.

At the time WCAG 1 was written, years before AJAX was the buzz-word for  
what was then well-known as DHTML, the classic example was form  
validation. Being able to use javascript to process a form and check it  
had been filled out before submitting it was all the rage in those days of  
slow servers, slow connections, charges for time or data volume, and so  
on. In that case, it made good sense to do server-side validation too.  
Indeed, one of the ways that various services were hacked is by relying on  
client-side validation - it's not hard to read the javascript, produce a  
page that claims to have validated and submit it, and I know of cases  
where serious security breaches were made this way, as well as cases where  
serious accessibility problems were resolved this way.

In a world of modern browsers, it will be possible to extend the  
functionality of assistive systems to better handle standard client-side  
scripting techniques, as well as extending the range of markup objects  
available to authors so they don't have to do things with javascript. But  
experience shows that the overall update time for browsers is years - the  
most-used desktop browser hasn't even released a new version in the last 5  
years.

There are some AJAX techniques that represent bad coding. Making these  
particular techniques accessible will, of course, be more difficult or may  
be impossible. But in general what people are trying to achieve can be  
done accessibly, and in a variety of ways. Ways that conform to WCAG 1.0  
even, and are therefore useful in the mobile world where the vast majority  
of browsers still don't support Ajax (Opera 8.5, last year, was the first  
mobile browser to provide reasonable Ajax support, and still only to  
relatively high-end phones).

Making an accessible application in AJAX is sometimes slightly harder than  
making an inaccessible one. But like most things, it turns out not to be a  
proportionally substantial effort, if you start from the premise that it  
has to be accessible, while it can be a nightmare if you start trying to  
thread accessibility through pre-written, badly designed code.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9 now! http://opera.com

Received on Monday, 17 July 2006 16:19:31 UTC