Accessibility of applications using XMLHttpRequest
Is anyone else as concerned as I am about the proliferation of this technology with respect to accessibility?
I'm not even talking about the script/noscript issue that using it to replace conventional post/response functionality can create, because that's easily solved through proper degrading.
What I'm more concerned about is that applications developed using this technology don't log history events as they process, and offer (as far as I can see) no means to identify to a script-capable screenreader that the document has changed - values updated, or whatever.
Conventional post/response creates those events through its own mechanics, and all browsers know what they are, because they're part of HTTP; but where that's replaced, these users won't be properly catered for.
Am I making sense here? I can't think of any way round that, and I'm basically inclined to disencourage the use of this technology altogether, until these issues can be resolved.
I appreciate there's a value for applications that would otherwise not be possible - you could quite reasonably argue that loss of accessibility is less critical if it's for something that would otherwise not be possible for anyone.
But that's not going to happen, is it? We're going to see more example of gmail, or apple's ridiculous live search - applications will use it as the sole mechanism; or improperly as the primary mechanism (improperly = relying on the noscript paradigm, which this group of users isn't catered by at all); or fall back on the separate rich/plain version dichotomy that we argue so hard against; all of this will increase the overall amount of inequality in access to web applications.
I would like to find or think of solutions to these issues ... because it offers exciting possibilities. But in the absence of being able to, I have to consider XMLHttpRequest a largely-unsuitable and immature technology, because we don't have the framework to handle the problems it creates (and because it's not a public standard, but I won't go there...)
Share: 
That's a well-thought out, insightful summary of xmlHttpRequest, Brothercake. I hadn't considered the issue of whether or not it informs a script-capable screen reader that the document has changed, and it would be good to get some results from people using assistive devices to find out for sure.
I've been concerned about Ajax for different reasons. It appears to be the "must-have" technology at the moment, and a lot of uses for it seem to be contrived. I do see a need for it, but its strength is for web applications, rather than traditional web documents. It reminds me a bit of when Flash first arrived on the scene, and everyone felt the need to learn Flash in order to showcase their skills, with little regard to the true usability of what they were doing. Thankfully, a lot of Flash developers do now care about accessibility and usability.
The standards compliance issue is also important to me. It will be interesting to see how the W3C's load and save pans out with respect to accessibility. I suppose the bottom line will be how user agent vendors implement the technology. Guideline 6 of UAAG [priority 1], requires that APIs do communicate with assistive technologies, but obviously, there's no guarantee that they'll adhere to the guidelines, which could well be the case with xmlHttpRequest at the moment.
Share:
| brothercake wrote: |
| Is anyone else as concerned as I am about the proliferation of this technology with respect to accessibility? |
Yes. Also, http://www.bestkungfu.com/archive/date/2005/03/ajaxessibility/
Share:
And http://www.standards-schmandards.com/index.php?2005/03/01/16-ajax-and-accessibility is a starting point.
There's two aims to make XmlHttpRequest based scripts accessible.
* Graceful degradation with JavaScript disabled
* Notifying which parts of the page has changed.
The first is obvious, and required. The second is interesting. What I'm thinking about at the moment is to have a "message area / key area" that lists what has changed on a page - much like your history log. Accessible via an accesskey, and/or high up on the tab order, and/or skip links. If these messages are rendered so that a visitor can skip straight to the changed section(s) (via a label or skip links). Lots of internal anchors needed though.
My theory is that making this JavaScript accessible is doable - if its done smartly.
Share:
Interesting ... I expect a lot of improvement can be done at the application design stage, in terms of the "flow" nature of the application. For example, here's an easy example:
- a VoIP interface based on a dynamically updating list of contacts - you click a name to initiate a call, and the list itself regenerates every x amount of time. There's no issue here because users don't actually need to be notified that the list has just updated - they just wanna make a call.
But here's a more complex one:
- a shopping cart, which is updated as you go along, kind of like "one-click-ordering" from buttons next to each product. If a user is aware that this button will update the shopping cart, and they can get to it at any point by looking for "Shopping cart summary" in their headings-reading mode, or using an internal link or whatever, that's pretty cool. But to work successfuly that application would need good, and readily apparent, instructions - the user would have to know in advance how it's going to behave.
It's gets really sticky with things like the business card designer example at http://www.baekdal.com/articles/usability/usable-XMLHttpRequest/
That application changes and saves continually; a single action - leaving one field and going to another - may save the data, or reject an input with a validation warning, and it may do that for multiple inputs. If it rejects the data, the user needs to know straight away.
It occurs to me that you can force the focus to move - you can send focus to a link or a form element, and update the message directly inside that. But you're still working on an assumption - the user would still need to know in advance that this is going to happen ... and either way - that's dangerous business - moving the focus around for keyboard users is generally something I would never do .. you're moving their caret to a completely different place in the document (remember that scene in the Office, where he moves the girl in the wheelchair away so he can sit down? It's not entirely dissimilar).
tricky ... seems like what we need is a convention - a collective understanding of things that these applications should always have, which a user can always look for - such as what you mentioned - a "history log" and "notifications area" - that kind of thing.
Share:
Thanks, Isofarro; they're great links.
| Isofarro wrote: |
|
My theory is that making this JavaScript accessible is doable - if its done smartly. |
A lot of Ajax examples use innerHTML, or use the document object to write out the content. What if DOM methods were used instead, such as replaceChild? The benefits would be the same, but that technique should inform script-enabled assistive devices that content has changed. If it's implemented so it degrades gracefully, could call a server-side method for those without scripting enabled.
Share:
| gez wrote: |
| A lot of Ajax examples use innerHTML, or use the document object to write out the content. What if DOM methods were used instead, such as replaceChild? The benefits would be the same, but that technique should inform script-enabled assistive devices that content has changed. |
I don't understand - how would using proper DOM techniques make a difference?
Share:
some more links, which include some of the ones already mentioned -- http://www.fiftyfoureleven.com/resources/programming/xmlhttprequest/examples
(and I'm sure I'm not the only one who remembers "ajax" as an abrasive cleaning product?)
Last edited by brothercake on 15 Mar 2005 03:02 pm; edited 1 time in total
Share:
| brothercake wrote: |
| It occurs to me that you can force the focus to move - you can send focus to a link or a form element, and update the message directly inside that. |
Even simpler than that, by dynamically writing the link that fires off the XmlHttpRequest to something like <a href="#historyLog" onclick="someHttpFunction()"> - use the internal page anchor historyLog to list the changes that's occurred. someHttpFunc runs first, and since the onclick doesn't return a false value, the page "redirects" to #historyLog
| Quote: |
| But you're still working on an assumption - the user would still need to know in advance that this is going to happen ... and either way - that's dangerous business - moving the focus around for keyboard users is generally something I would never do |
Using the internal anchor approach, the effect should be similar to following an internal anchor - initiated by a click of a link (or whatever the keyboard equivalent is).
| Quote: |
| tricky ... seems like what we need is a convention - a collective understanding of things that these applications should always have, which a user can always look for - such as what you mentioned - a "history log" and "notifications area" - that kind of thing. |
Yep.
Share:
| Isofarro wrote: |
| Even simpler than that, by dynamically writing the link that fires off the XmlHttpRequest to something like <a href="#historyLog" onclick="someHttpFunction()"> - use the internal page anchor historyLog to list the changes that's occurred. someHttpFunc runs first, and since the onclick doesn't return a false value, the page "redirects" to #historyLog |
Hmm yeah, that makes sense - and that implies that such events have to be user-initiated by something you can capture and handle for these users - ie, no mouseover-triggered or automatic requests?
Share:
| brothercake wrote: |
| Hmm yeah, that makes sense - and that implies that such events have to be user-initiated by something you can capture and handle for these users - ie, no mouseover-triggered or automatic requests? |
Good point. I'm working from the example of a JavaScript powered blogging client (implementing the AtomAPI). Don't have a use case in mind for non-user initiated XmlHttpRequests. Hmmm... how about a frequently updated list of news headlines (like an aggregator). I'll have a think about that...
Share:
| Isofarro wrote: |
| Hmmm... how about a frequently updated list of news headlines (like an aggregator). I'll have a think about that... |
That particular case doesn't really matter though, does it? That can just sit there, with a last-updated date and time, ready for someone to want to read it. As long as it doesn't update *while* you're reading it ... which ... er ... actually no, I can't think of any way to prevent that.
But badly-made forms is what I was mostly thinking of, or the worst implementation case - interfaces which aren't forms at all - things where a user event triggers the request but is not handleable (or triggerable) in a screenreader - which is basically every event except onclick of links (no focus - readers don't generate them), and onclick, onfocus, onchange and onsubmit of form/elements, iirc.
Share:
| brothercake wrote: | ||
I don't understand - how would using proper DOM techniques make a difference? |
I was under the impression that changes made with DOM methods were exposed to assistive devices. Maybe that's just MSAA, or maybe there's no truth in it at all. I suspect I completely misunderstand it, as you know far more about scripting that me. I'm enjoying following the topic though, so I'll keep quiet and be a spectator
Share:
How much of what we are discussing is ontopic for the Web Content Accessibility Guidelines working group? I know I've volunteered some time to the Scripting Techniques part of the spec - isn't this part of the problem we are trying to solve there too?
Share:
| gez wrote: |
| I was under the impression that changes made with DOM methods were exposed to assistive devices. Maybe that's just MSAA, or maybe there's no truth in it at all. |
I think the latter ...
As far as I know there's no difference - all changes in the DOM (however caused) are exposed to MSAA, but no screenreaders explicitly report them.
There is a feature in JAWS which can fire the mouseover event of an element that has an "onmouseover" attribute handler, and then it tells you whether the page has changed as a result - maybe that's what you were thinking of? But I've tried that with a few simple scripts, and it doesn't really work .. I wouldn't care to rely on it as a programmer even if it did.
Last edited by brothercake on 15 Mar 2005 04:12 pm; edited 3 times in total
Share: