[Accessibleweb] AJAX and accessibility

[Dylan Wilbanks]

Based on the overall response, it seems like there is some ability for
assistive technology to work effectively with Ajax thanks to its use of the
DOM. However, I had Dan Comden take a look at a few AJAX-enabled items, and
it basically confirms my fears. (If Dan is willing to, maybe he can share
that on this list.)

The problem is that this is all so new that there is no best practices
literature surrounding AJAX technologies, much less how to properly code
AJAX for accessibility. It's just too new. I think this is a case of a
technology being way too far out ahead of the reality of things, and if AJAX
really takes hold in the next year we could see some severe problems with
web accessbility until the browser makers, AT developers, and coders catch
up.

(Not surprising, honestly, but you'd think that just once we could come up
with a technological step forward that doesn't require hasty and messy fixes
later for very basic problems the designers should have thought about
first.)

dw

> -----Original Message-----
> From: Matt May [mailto:mcmay at w3.org]
> Sent: Friday, June 10, 2005 2:19 PM
> To: Rick Ells
> Cc: Dylan Wilbanks; accessibleweb at u.washington.edu
> Subject: Re: [Accessibleweb] AJAX and accessibility
>
>
> Ajax is shorthand for script that enables ad hoc protocols between the
> client and the server. It's elegant bits of code that amount to an
> ungodly hack on JavaScript.
>
> Now, the good news is that this is protocol-based work on top of a
> format which we can make reasonably accessible. The bad news is that
> it's not one protocol, it's a potentially infinite number of protocols,
> depending on framework and implementation details. So we don't get
> readable data until it comes out of the Ajax sausage-making machine. At
> this point, unless we in accessibility want to make a sausage machine of
> our own for the sake of assistive technology (which we don't, because it
> would never be used), we'll have to rely on the updates that come from
> Ajax calls to be inserted using the DOM rather than innerHTML or
> document.write() calls, and for ATs to render that information properly
> to their users.
>
> I can't say much, other than that we're working on it. The new XHTML 2
> draft[1] has a new attribute called role which is at least a piece of
> the puzzle, and we're busy finding more pieces as we go. It's like a big
> game of Pokemon. :)
>
> -
> m
> [1] http://www.w3.org/TR/xhtml2/
>
> Rick Ells wrote:
>
> >
> > I was not sure what AJAX was so I found the following page:
> >   http://www.adaptivepath.com/publications/essays/archives/000385.php
> >
> > This sounds like a rebirth of the Dynamic HTML application pages that
> > died in the late 90s because of inconsistencies at the time in HTML,
> > CSS, Javascript, and browsers. All four are more standardized now, so
> > I suppose the effort is inevitable.
> >
> > I would wonder how this relates to the ECMAScript effort to
> > standardize and rationalize Javascript. That effort, and its
> > relationship to accessibility is discussed at...
> >   http://www.webstandards.org/learn/faq/#p2231
> >
> > It seems to me that the wildcard in this effort is the browser. IE
> > still is not compliant with the standards behind dynamic HTML, which
> > means this route may lead back to designing for specific browsers or
> > testing for browsers and maintaining complex code to address the
> > peculiarities of each.
> >
> > If AJAX works by manipulating objects through the Document Object
> > Model (DOM) and everyone sticks to the standards, it seems possible to
> > me that
> > adaptive and assistive technology could interact with AJAX pages - the
> > attributes are built into HTML and programatically accessible. Someone
> > has to figure out how to handle all the permutations and deliver it as
> > intellible responses to the person using the adaptive technology.
> >
> >
> >  |- Rick Ells - 543-2875 - rells at cac.washington.edu - Rm 011S
> MGH Bldg -|
> >  |-                http://staff.washington.edu/rells/
>        -|
> >
> >
> > On Fri, 10 Jun 2005, Dylan Wilbanks wrote:
> >
> >> I went to the Adaptive Path workshop yesterday here in Seattle. It
> >> was an
> >> interesting experience (one in which I learned that networking with
> >> three
> >> pints of beer in your system is a dumb idea :) ). During the question
> >> time,
> >> though, the attendees peppered Jesse James Garrett with questions about
> >> AJAX. Not surprising, since he coined the term and has been the drum
> >> major
> >> at the front of this new move forward. But, in the midst of his
> >> description
> >> of AJAX, something really started to trouble me. I think it will turn
> >> into a
> >> blog entry or an article at some point in the future, but I wanted to
> >> start
> >> here, since this group is loaded with the smart people who could tell
> >> me if
> >> I'm off or not.
> >>
> >> My thesis is this: AJAX is not an accessible technology, because it's
> >> trying
> >> to be an application in a hypertext environment.
> >>
> >> AJAX is trying to give the behavior of an application to web sites.
> >> Look at
> >> Google Maps vs. Mapquest. Where Mapquest requires clicking on links to
> >> request information from the server, Google Maps is using JIT XML
> >> calls to
> >> seed the tiles into the browser window, stashing some of them off the
> >> viewing screen and pulling them into position as they are needed, so by
> >> dragging and zooming the map you have a "smooth" feeling experience
> >> -- you
> >> can follow the path from point A to point B without waiting for 200
> >> clicks
> >> or so. Google Maps behaves like an application would, where data is
> >> stored
> >> locally and the speed of the data pull isn't driven by clicks.
> >>
> >> Now, as I understand things, accessibility aids such as screen
> >> readers are,
> >> in the case of browsers, driven by events such as keyboard commands
> >> (e.g.
> >> tabbing through links) and the (re)loading of pages into the window.
> >> So, a
> >> screen reader isn't going to necessarily know what's going on in a page
> >> controlled by AJAX because there's no event trigger. Maps (for the most
> >> part) aren't going to have problems with AJAX, but think about
> an online
> >> form. You fill out a form and trigger the submit button. In standard
> >> (X)HTML, the form will then send the data (POST||GET) to the server,
> >> and the
> >> server will return data to a confirmation page. AJAX isn't going to
> >> do that;
> >> it's going to return the message right back to the same window... and
> >> not
> >> trigger a refresh. How is a JAWS user going to know if his/her
> >> information
> >> was received and there were no errors if there's no trigger for the
> >> screen
> >> reader to tell them so?
> >>
> >> The problem I'm seeing is that accessibility aids are going to have
> >> to start
> >> figuring out how to handle JavaScript, and it may require AJAX
> >> developers to
> >> put "hooks" in their code to tell the aids when something's happened.
> >> In the
> >> meantime, current users who require accessibility aids won't be able
> >> to use
> >> AJAX-driven web pages, especially if critical information is buried
> >> in the
> >> AJAX-driven events.
> >>
> >> If I'm off-base on this last part, please tell me. I don't have JAWS
> >> on this
> >> computer, so I can't tell you what it does with AJAX sites.
> >>
> >> BTW, I asked Garrett about my perceived problem with accessibility with
> >> AJAX. His response was, in a nutshell, that everyone else will just
> >> have to
> >> catch up. I don't like that response, since it reminds me too much of
> >> what I
> >> heard from the Flash camp a few years ago.
> >>
> >> dw
> >
>
>