RE: Frames (was Re: dynamic content )

<<
The visibility of HTML Frames is an option left to the author. At many
framed sites I visit there are no frame borders; content from multiple
frames appear merged as a single body of content. Unless one of the frame's
contents exceeds its visible are and gains scroll-bars on the side, I can't
tell that the site is framed, and neither can a screen reader. There is no
"window boundary" to make the distinction.
>>

Despite the term "screen reader", a accessibility aid that reads the screen
is also aware of window boundaries, regardless if they are drawn with a
visible boundary or not.  Technically, screen readers use a off-screen model
that correlates each drawing operation to a particular "window".  In this
case, I use the term window as a programming construct.  A window is a
element of the Windows operating system.  Windows may or may not have visual
boundaries.

Nonetheless, the screen reader is aware that it is crossing a frame
boundary, because each frame is kept in a separate window element.

-----Original Message-----
From: Chris Kreussling [mailto:CHRIS.KREUSSLING@ny.frb.org]
Sent: Thursday, January 28, 1999 7:21 AM
To: w3c-wai-gl@w3.org
Subject: RE: Frames (was Re: dynamic content )


>>> <w3c-wai-gl@w3.org> (Charles Opperman) 01/27 7:41 PM >>>
<< (Wendy Chisolm)
While Netscape does not allow you to "turn off" frames, it will let you
open a selected frame in a new window.  The problem with frames and screen
readers is similar to that of tables and screen readers, i.e. it will read
across the frames as one garbled sentence.  
>>

Are you certain this is still a problem with current screen readers?  Each
frame is drawn in it's own particular window.  The screen reader "knows"
that there are two windows.  If the screen reader is reading across frame
boundaries, it's because it's ignoring the window boundary.

A similar example is with the Windows Explorer.  There is a tree on the left
representing the hierarchy of the file system, with the particular files
shown in the right side window.  Screen readers do not read across those
windows.

So while older screen readers might have ignored the frame boundary, I
believe that most of them have updated to respect the window boundary and
use programmatic means, such as Active Accessibility to get the information.
<<<

I want to make a semantic distinction here about "screen readers" versus
other enabling technologies.

The visibility of HTML Frames is an option left to the author. At many
framed sites I visit there are no frame borders; content from multiple
frames appear merged as a single body of content. Unless one of the frame's
contents exceeds its visible are and gains scroll-bars on the side, I can't
tell that the site is framed, and neither can a screen reader. There is no
"window boundary" to make the distinction.

A program which is not "looking" at the screen, but is programmatically
intercepting or interpreting non-visual information about the document or
its presentation is no longer "just" a screen reader, its something else.
For example: although I haven't had the opportunity to use it, I understand
that PWWebSpeak is an enabling Web Browser, not a generalized screen reader.
Because it understands HTML and the underlying structure, its no longer
limited to "reading across the screen;" it can understand tables and frames
as distinct containers and present them to the user appropriately. A program
which intercepts Windows system calls to interpret how the underlying
program builds an image on the screen would also not be a screen reader.

<author>Chris Kreussling</author>
<disclaimer>The views expressed are 
those of the author and do not necessarily 
reflect the position of the Federal Reserve 
Bank of New York or the Federal Reserve 
System.</disclaimer>

Received on Thursday, 28 January 1999 19:42:51 UTC