replicating tables with CSS and Divs

[WebcastMaker]

tables-based layouts
don't have any inherent accessibility problems.

Incorrect, any proper [1] talking browser would announce the start of
tabular data when it encounters a table element.
[1] Most talking browsers are crap, most assume that nobody uses tables
correctly. Following this strategy is admitting defeat, don't let bad
coding win. Don't use tables for layout.

In theory this is all well and good, but until the browsers (all of
them) follow the rules, I believe you should use what ever technology
you need to, in order to get the job done.

Today some reader may have problems with tables for layout. But the
site is not inaccessible, just a pain. On the other side of the coin
some browsers (albeit mostly IE) has problems with all css, again it
does not make the site inaccessible, just a pain.

There is a middle ground. That is, use which ever is best for your
design. Sometimes tables, sometimes css, sometimes both.

ymmv

 

[Spartanicus]

As this leads to more need for semantic markup and clearer more accessible
pages in general, I want to believe. But one question is niggling me: if
the UAs won't recognize semantic table use

I haven't tried all of them, so there may well be exceptions.

why would authors change to meet them?

I can't speak for "authors". The question is do we want to author
content that is correctly marked up or not. If so then there's no
argument for using tables for layout, just as we wouldn't markup a
navbar as a paragraph, or mark up a paragraph as a list.

And if authors continue to use table markup presentationally,
why would UAs ever change?

Making assumptions about how UAs handle markup is bound to fail, there
are to many UAs to consider, their function is to disperse (visual,
aural, bots etc.), and they are a moving target. The process of marking
up content should be disassociated from how UAs may or may not handle
it. Coders can do their bit by authoring correctly marked up content,
innovation of UAs should be left to their developers.

 

[jake]

If you or another can recommend one that's free (or has a trial long
enough to allow me to get used to it) and can be reasonably downloaded
with dialup, and doesn't require me to compile it, AND is worth the
time, I will do exactly that.

"........... reasonably downloaded with dialup ........." is the
problem.

Most popular readers/browsers (JAWS, Window Eyes, HPR, HAL, etc.) have
trial downloads available, but they're in the 30-50Mb range.

Someone else may know of another source that's smaller.

regards.

 

[Kris]

Spartanicus' point that speech browsers could deal far better with
data tables if they could be sure that the majority of tables were for
data is true, but applies to non-speech browsers as well [1].

[1] Wouldn't it be nice if you could select a table column and get the
average, standard deviation and total calculated automatically -
convert data tables into a mini read-only spreadsheet through the UA?
On a typical tables-for-layout page the additional screen furniture to
do this would clutter things up.

One could follow accessbility recommendations and supply a summary of
the table in the table attribute. Screenreaders could perhaps comvey the
difference between a layout table and a data table through the presence
of the summary attribute. Or make the user decide how to read the table
aloud after the summary is read.

 

[Chris Morris]

Spartanicus' point that speech browsers could deal far better with
data tables if they could be sure that the majority of tables were for
data is true, but applies to non-speech browsers as well [1].

One could follow accessbility recommendations and supply a summary of
the table in the table attribute. Screenreaders could perhaps comvey the
difference between a layout table and a data table through the presence
of the summary attribute.

I've seen enough summary="layout table" and similar to doubt that this
would work. <th> might be more reliable, but still not completely.

<caption> seems more reliable than summary= for getting read in the
current browsers, incidentally. Generally I think <caption> makes
summary unnecessary for most tables - I've never been entirely sure
what the difference between the data for the two is in most real-world
applications.

Or make the user decide how to read the table aloud after the
summary is read.

Effectively (summary or not) this happens - HPR will normally read
tables by linearising them, but can be put into a table-reading mode
where you can move around the cells.

 

[jake]

Incidentally -- referring to your original post -- tables-based
layouts don't have any inherent accessibility problems.

[Assuming properly linearising ones, of course]

Yes they do. Try viewing an even slightly complex table layout in
links, w3m, OpenWave or WebTV. The first two give horizontal scrolling
which is far more of an inconvenience in text mode than in graphics
mode. The latter two (especially OpenWave) don't allow horizontal
scrolling, and so give columns two characters wide.

All of this is tolerable for data tables (on anything except OpenWave
rarely a problem anyway), though still irritating on the wider
ones. It's unnecessarily introducing a problem otherwise.

There's other more minor side effects, but they can make sites very
difficult to use in those four browsers.

Some might argue that this isn't an accessibility issue because none
of those four browsers are designed for users with disabilities, but I
would say that that was taking an unnecessarily narrow definition of
accessibility.

'Usability' would be a better word to use in the case you describe.

regards.

 

[jake]

[snip]

Any that don't linearise properly, for exactly the same reason that
they'd mess up accessibility in Lynx.

Ones that linearise in a sensible fashion generally aren't a problem
for speech browsers,

My point exactly.

but they can be a problem for others (see my
other post).

'Usability' problems. How differently would those visual browsers deal
with non-tables based layouts?

Spartanicus' point that speech browsers could deal far better with
data tables if they could be sure that the majority of tables were for
data is true, but applies to non-speech browsers as well [1].

The Web is 99% tables-based. Readers have to deal with any page on that
basis, so it makes sense not to announce tables.

Modern talking browsers or screen-readers can deal more than adequately
with data tables.

regards.

 

[Chris Morris]

'Usability' would be a better word to use in the case you describe.

The two are very closely related, though. My definition of an
accessible site is one that can be used with any browser and by any
user (obviously not all browser-user combinations may be suitable). In
that way,it's as much of an accessibility problem as low [1] colour
contrast - it doesn't stop the content being accessed, but it does
slow down things for some users.

[1] Poor rather than unreadable

 

[Isofarro]

In message <[email protected]>, Kris

Most modern ones handle tabular data really well.

I haven't noticed one that can tell a data table apart from a layout table
correctly.

 

[Isofarro]

Screenreaders could perhaps comvey the
difference between a layout table and a data table through the presence
of the summary attribute.

summary="layout table" -- now what? Evaluating the string content isn't a
viable option either, since the HTML recommendation doesn't define a
limited range of values.

 

[Isofarro]

jake wrote:
[Please do not snip attributions]

Chris Morris mentioned:

Spartanicus' point that speech browsers could deal far better with
data tables if they could be sure that the majority of tables were for
data is true, but applies to non-speech browsers as well [1].

The Web is 99% tables-based. Readers have to deal with any page on that
basis, so it makes sense not to announce tables.

Wonderful - you've just succeeded in making it difficult to present tabular
data to a screen reader.

 

[Isofarro]

if
the UAs won't recognize semantic table use, why would authors change to
meet them?

I guess now you've noticed the problem a layout table creates - or any
misuse of structural elements for non-structural purposes - it becomes
difficult to distinguish the use from the abuse, so the proper usage of
structural markup - which screen readers can find beneficial - suffers.

 

[Isofarro]

UAs do not announce tables so there is no extraneous verbiage to confuse
the listener when processing a page which uses layout tables (most of
the Web still uses tables for layout).

However, the listener can navigate a data table via keyboard

And a data table is announced to the visitor how? (Considering you've taken
great pains to state that "UAs do not announce tables".)

 

[WebcastMaker]

I haven't noticed one that can tell a data table apart from a layout table
correctly.

Man where have you been?

 

[The Doormouse]

I haven't noticed one that can tell a data table apart from a layout
table correctly.

Layout tables usually contain images, and generally are nested.

Nesting is a presentation technique which probably has no use for a pure
data format. IMO.

The Doormouse

 

[jake]

I haven't noticed one that can tell a data table apart from a layout table
correctly.

But it doesn't stop them from handling tabular data really well.

regards.

 

[jake]

jake wrote:
[Please do not snip attributions]

Chris Morris mentioned:

Spartanicus' point that speech browsers could deal far better with
data tables if they could be sure that the majority of tables were for
data is true, but applies to non-speech browsers as well [1].

The Web is 99% tables-based. Readers have to deal with any page on that
basis, so it makes sense not to announce tables.

Wonderful - you've just succeeded in making it difficult to present tabular
data to a screen reader.

Welcome to the planet Earth.

To save a long explanation, it might be easier if you got hold of a
modern reader/browser and saw for yourself.

regards.

 

[jake]

And a data table is announced to the visitor how? (Considering you've taken
great pains to state that "UAs do not announce tables".)

Let's say I'm on a page dealing with temperature fluctuations on the
south of Spain.

The browser talks about temperatures and then starts saying:

"Temperatures recorded in the San Carlos region in June 2002"
All temperatures in degrees Celsius
Date
Temperature (Maximum)
Temperature (Minimum)
first
18
22
second
18
24
............... etc.

You don't need to be a rocket scientist to know you're listening to a
data table.
(Of course the caption could just as easily have said "Table of
Temperatures recorded ......")

However, at this stage, if you want to, you can pause and go into 'table
reading mode'.

As you move across the cells you hear:
Date: twenty-second
Max: 18
Min: 24
................. etc.


People with a sight-impairement have a disability; they're not stupid.

regards.

 

[Kris]

Screenreaders could perhaps comvey the
difference between a layout table and a data table through the presence
of the summary attribute.

summary="layout table" -- now what? Evaluating the string content isn't a
viable option either, since the HTML recommendation doesn't define a
limited range of values.[/QUOTE]

Honestly, the amount of instances on the web in which a layout table has
a summary attribute must be very small.

I am more in favor of a way for SR users to intervene easily after a
summary (or caption) has been read.

 

[jake]

summary="layout table" -- now what? Evaluating the string content isn't a
viable option either, since the HTML recommendation doesn't define a
limited range of values.

Honestly, the amount of instances on the web in which a layout table has
a summary attribute must be very small.

I am more in favor of a way for SR users to intervene easily after a
summary (or caption) has been read.
[/QUOTE]
That last sentence is interesting. Could you expand on it?

regards.