W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2008

RE: JavaScript and Screen Readers

From: Ryan Jean <ryanj@disnetwork.org>
Date: Mon, 18 Aug 2008 15:21:44 -0400
To: "'Phill Jenkins'" <pjenkins@us.ibm.com>, <w3c-wai-ig@w3.org>
Message-ID: <E1KVAKU-0005L9-Fd@bart.w3.org>
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.



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

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

Phill Jenkins
IBM Research - Human Ability & Accessibility Center
Received on Monday, 18 August 2008 19:24:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:37 UTC