RE: JavaScript and Screen Readers

I totally agree with you here. That is what I'm trying to do. I want the
screen reader to return to the top of the page, however the screen reader
does not read on. Yes, the user activates the link to the "document.write()"
function and they do know what is happening. The information is still
accessible as it reads before the link is activated, but once it is, the new
information is not readable by a screen reader. It's the same exact
information by the way.

 

Sincerely,

Ryan Jean

Assistant IT Specialist

The Disability Network

Flint, MI

 

  _____  

From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf
Of Phill Jenkins
Sent: Monday, August 18, 2008 12:52 PM
To: w3c-wai-ig@w3.org
Subject: 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