W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2001

Re: Table columns and screen readers

From: David Woolley <david@djwhome.demon.co.uk>
Date: Thu, 1 Feb 2001 08:15:12 +0000 (GMT)
Message-Id: <200102010815.f118FCo19608@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org
> I would have thought that most screen readers would be able to read 
> the first cell's contents, then the next cell etc etc -- rather than 
> reading right across the page and turning it all to mush.

A screen reader will read across the column boundaries unless it
manages to sense the blank area between columns.  From what I've heard,
JAWS is not a screen reader but actually accesses the document object
model and may linearise the table sensibly, at least when used with
IE.  (I guess Windows screen readers must intercept the GDI calls that
write text to the screen, as the only other alternative is OCR, albeit 
with consistent character shapes.  As such, they will have some 
information about the order in which the program refreshed the screen,
which may not be the logical order, even when none of the window is
ever obscured and will be controlled, to some extent, by Windows,
when there is an obstruction.  Can anyone give some first hand knowledge
here?)

Accessing such a table in Lynx will also linearise it.

The real problem is that tables often are not as simple as this.
It's quite likely that the linearised form of a table will actually
be:  navigation menu, top banner and menus, real text, producing a
lot of noise to be bypassed.

As I remember the WCAG rules, using tables for layout is tolerated and
the preferred method until browsers properly implement CSS, but the
tables are required to linearise correctly, which, in my view, would
probably mean giving the main text first in the above example.
Received on Thursday, 1 February 2001 18:22:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:53 GMT