Asynchronous page updates are a reality of modern web apps. It's how Gmail, Google Maps, MobileMe, and countless other online services work. It's not at all specific to a single JavaScript framework.
Yeah, my concern is that one of these frameworks becomes sexy enough that everyone starts using them, thereby sending the web back into the accessibility dark ages!
Asynchronous apps can be made to work in the context of an application designed with accessibility in mind -- but you have to work out ways of notifying the screen reader that things are happening after the page has finished loading. Part of that work may well involve lobbying the screen reader makers to pay attention to the fact that the web has evolved just a tad.
This part puzzles me. Why does the complexity of the JavaScript matter at all to the screen reader. It's not actually running the JavaScript, is it? Is the issue in determining visibility? This is a completely open-ended question -- I'm truly curious about the answer.
Well, it actually does depend on the screen reader, but my rule of thumb has been the screen reader reads what you see if you view the HTML source code -- anything generated at runtime after the page loads is beyond its scope. That's why the accessibility best practice is to develop the fully working app as pure HTML with form submits, etc., and then overlay the javascript to animate and asynchronise everything. Then a user with visual disabilities can simply turn off the javascript and work normally with the application.
The thing is, even Flash these days can be made to be accessible - the API has hooks available to the OS for screen readers, but you have to turn them on and work with them proactively. Pure javascript apps don't allow that right now.
by Nick Caldwell — Sep 07
Yeah, my concern is that one of these frameworks becomes sexy enough that everyone starts using them, thereby sending the web back into the accessibility dark ages!
Asynchronous apps can be made to work in the context of an application designed with accessibility in mind -- but you have to work out ways of notifying the screen reader that things are happening after the page has finished loading. Part of that work may well involve lobbying the screen reader makers to pay attention to the fact that the web has evolved just a tad.
This part puzzles me. Why does the complexity of the JavaScript matter at all to the screen reader. It's not actually running the JavaScript, is it? Is the issue in determining visibility? This is a completely open-ended question -- I'm truly curious about the answer.
Well, it actually does depend on the screen reader, but my rule of thumb has been the screen reader reads what you see if you view the HTML source code -- anything generated at runtime after the page loads is beyond its scope. That's why the accessibility best practice is to develop the fully working app as pure HTML with form submits, etc., and then overlay the javascript to animate and asynchronise everything. Then a user with visual disabilities can simply turn off the javascript and work normally with the application.
The thing is, even Flash these days can be made to be accessible - the API has hooks available to the OS for screen readers, but you have to turn them on and work with them proactively. Pure javascript apps don't allow that right now.