@Nick Caldwell: you have to work out ways of notifying the screen reader that things are happening after the page has finished loading
I agree in theory, but I think you need to take your case to the makers of the screen reader apps and/or the browsers. The authors of JavaScript libraries really aren't in a position in enforce any sort of policy. They can feed metadata to the browser, but the browser has to be listening for it.
Based on my limited knowledge of plug-ins, it seems to me Flash is in a somewhat different situation since it's like a little app (a native plug-in) running on the computer itself. The plug-in already makes direct API calls on the client side. Adobe also defines both the format and the reader implementation. I haven't written a browser plug-in, though, so don't take this at face value.
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.
Certainly that works when the app is form-centric, but there are many kinds of applications that don't involve the user inputing structured data in pre-determined set of text boxes. In those cases, I don't know if it's clear what to do.
by Scott Stevenson — Sep 07
I agree in theory, but I think you need to take your case to the makers of the screen reader apps and/or the browsers. The authors of JavaScript libraries really aren't in a position in enforce any sort of policy. They can feed metadata to the browser, but the browser has to be listening for it.
Based on my limited knowledge of plug-ins, it seems to me Flash is in a somewhat different situation since it's like a little app (a native plug-in) running on the computer itself. The plug-in already makes direct API calls on the client side. Adobe also defines both the format and the reader implementation. I haven't written a browser plug-in, though, so don't take this at face value.
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.
Certainly that works when the app is form-centric, but there are many kinds of applications that don't involve the user inputing structured data in pre-determined set of text boxes. In those cases, I don't know if it's clear what to do.