Comments on: Ajax, Hijax and accessibility

By: Max Kiesler - Designer » Blog Archive » How to Make Your AJAX Applications Accessible - 40 Tutorials and Articles

Tue, 02 Jun 2009 08:47:25 +0000

[...] Ajax, Hijax and accessibility [...]

By: Troels Wittrup

Troels Wittrup — Thu, 23 Feb 2006 23:03:11 +0000

I agree that Ajax is here to stay. Hijax is the next step. By Hijax I also refer to the mechanism of indirect Ajax, where the web 1.0 post back is suppressed and replaced (the post back is hijacked) with an out of band call (XmlHttp) to the server. A web server and screen reader can transfer pages using different compression methods, so of course you can develop a screen reader that supports Hijax internally. Infact if you look at one of the latest Hijax frameworks you'll notice that direct Ajax programming is moving away from DOM manipulations and over to business logic, and Hijax is taking over the DOM-manipulations. But why not let the browser handle the Hijaxing internally? That is what happens in the Windows Application framework, the window manager takes care of the screen updates. Hijax is the window manager for web forms... So, screenreader developers out there: Look closely at the Hijax frameworks out there and draw up som standards, so that a Hijax-enabled web server can send only modified bits to a Hijax-enabled screen reader. In that way we will be able to have nice responsive applications on the web and browsers that are Hijax-enabled will be able to access these applications without having to download a Hijax framework together with the content.

By: Jeremy Keith

Jeremy Keith — Mon, 20 Feb 2006 15:59:32 +0000

True, but remember that the problem lies with generated content in general, not Ajax in particular. The crux of the matter is having screenreaders recognise that a portion of the currently loaded page has been updated – whether that update came from the server or not is academic. So the problem does lie with standards: using the DOM in combination with ECMAScript to update a page written in (X)HTML after the page has finished loading. Throwing XMLHttpRequest into the mix does add a proprietary technology but, in this case, it’s a red herring. The real issue lies with how screenreaders cope with technologies that do have the standards stamp of approval.

Thanks very much for the kind words about the workshop, Bruce. You neglected to mention what a great audience I had. In particular, there were some terrific questions asked. My personal favourite was when you asked a question about some code I had up on-screen and the answer to your question was revealed in the very. next. slide. Such timing! I love it when a workshop comes together.

By: bruce

bruce — Sat, 18 Feb 2006 11:34:13 +0000

Of course, I’m talking bollocks. The XMLHttpRequest thingie that powers Ajax isn’t Standard at all. It’s some Microsoft invention that everyone else supports as well.

By: Bruce

Bruce — Sat, 18 Feb 2006 10:12:49 +0000

But Ajax is standardised: JavaScript (ECMAscript), xhtml, the DOM …

By: Matthieu Faure

Matthieu Faure — Sat, 18 Feb 2006 09:51:37 +0000

IMHO the question is not whether we should (or not) use technologies not implemented in AT (assistive technologies). The real point is if technologies are not standardized (eg W3C stampped), there is:

1) no serious way for AT vendors to implement them.

2) not much hope that accessibility be really, sufficiently considered by technology creator.