Re: JavaScript and Screen Readers

> document.write() 
> . . .   How about Model-View-Controller with Controller in 
> JS?  . . . "view components" may make up an entire ui 
> whereby only one bit may change.  This would be a challenge 
> for a screen reader, I'd think, because you'd have to restart 
> reading of the screen if text that's already been read changes.

That is exactly one of the potential issues.  Upon the document.write() 
event, the DOM is reloaded and the screen reader starts reading back at 
the top on the document.  There is no old API or way for the screen reader 
to know just what part was changed without taking a performance hit and 
trying to guess with heuristics. 

The other issue is events -  and who causes them.  If the document.write 
occurs as a result of the user selecting a link or some other user 
controlled event, then it can be explained to the user what will happen 
and how to "handle it".  But if some random event cause the page to 
reload, for example some push advertising re-loads the image for the 
advertisement, then the users has no warning or control to stop or pause 
that - a big accessibility issue.

Hence the invention of ARIA - Accessible Rich Internet Application spec 
that allows not only the specification of the "U I  components, but also 
the asynchronous updating of them without having to do a whole 
document.write thing.  But developers still have to understand and give 
the end user control over events, such as clicking on links, selecting 
from controls, etc. such that if the users does nothing, nothing changes 
out from under him.

See also http://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation

Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able