E-mail List Archives
Re: What motivates you? and accessibility checks
From: Prof Norm Coombs
Date: Mar 8, 2000 4:05PM
- Next message: Cyndi Rowland: "Re: What motivates me?"
- Previous message: Prof Norm Coombs: "Re: What motivates me?"
- Next message in Thread: Cyndi Rowland: "Re: What motivates me?"
- Previous message in Thread: Prof Norm Coombs: "Re: What motivates me?"
- View all messages in this Thread
Tables aren't bad depending . . .
even with an old browser if the screen reader reads left to right it can
make sense. Look at our home page: http://www.rit.edu/~easi
even where there 2 or 3 links across the page, anyone used to the web would
guess these were links side by side. For a simple layout like this no
Even if you have a table like:
hotel 2 nights $100 $200
That reads easily
More of a problem would be
Even without headers, you might guess in the second example by the layout
that there were 2 nights totaling $200. By screen reader unless I examine
it carefully, I don't know that the 2 $100s are under each other. Seeing
them under each other, you can make some assumptions. Just hearing it, for
all I would know is that the $100 on the second line is right under the
So long as each cell has one line in it all across and none have 2 lines,
the logic can be guessed. When some cells have 2 items under each other,
it is confusing.
In windows 3.0 under multimedia or some such item, there was an item called
sound record, but on the screen it was
Hope this clarifies the nature of the problem a little.
At 02:24 PM 3/8/00 -0700, you wrote:
><snip> It is still recommended by standards though that tables not be used
>formatting. <end snip>
>The actual guideline says this: "5.3 Do not use tables for layout unless the
>table makes sense when linearized."
>For the most part, what this means is that the table needs to make sense if
>you read the table one cell at a time starting with the top left cell and
>proceeding across the row until the end, then going to row two and reading
>each cell. However, some of the older screen readers were incapable of
>reading tables correctly. They would read from left to right, ignoring the
>fact the the content was in separate cells. It would be like putting a piece
>of paper on the screen and reading each line all the way across the screen,
>then moving the paper down and reading the next line. This renders the
>content in an unintelligible fashion. For the most part, though, current
>technologies (even screen readers) have no trouble reading tables. Where you
>can get into trouble is if you have really complex table structures with
>cells that span columns in unusual ways, etc. Nested tables (tables inside
>of tables) are not always bad, but you have to be careful with them too.
>Screen readers will usually read the entire contents of a cell (including
>any nested tables) before moving on to the next cell. If this is how you
>want your content to be read, then you're probably ok.
>Still, things would be much better if current browsers supported style sheet
>positioning better. Internet Explorer does quite a nice job. Netscape
>doesn't. In fact, pages become more INaccessable in Netscape when style
>sheet positioning is used because you can't use the tab key to navigate the
>page anymore. In my opinion this is a fatal flaw which I cannot ignore, so I
>do not yet use style sheet positioning. I do use tables, but only because I
>don't think there is a viable alternative at this point, due to lack of
>browser support. I look forward to the day when I can use them "without
>When I use tables for layout, I give the table a title and a summary. The
>title will show up as a visible "tooltip" when the mouse runs over the
>table. In the table SUMMARY I simply say "table used for layout" or
>something similar. The TITLE might say something like "Main content of page"
>or "navigation links" or similar. The summary attribute remains invisible.
>Here is some sample code:
><table title="Main Navigation Menu" summary="Table used for layout"