replicating tables with CSS and Divs

[Isofarro]

Layout tables usually contain images, and generally are nested.

"usually" is too vague to be of use. Tabular data can contain images.
Tabular data can also - in circumstances be nested.

Modern table layouts are simple tables with no nesting. Still the problem
remains.

 

[Isofarro]

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

Stopping accessibility is a priority 1 issue. A priority 2 issue is one that
makes it difficult to access.

 

[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.

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.

More unsatisfactory assumptions.

 

[Isofarro]

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.

Not all tabular data is so straight forward - and even for a simplistic
example you provide, a screen reader user needs to backtrack. Now much
simpler would be to simply announce a table was encountered - that reduces
the barrier to access somewhat.

 

[jake]

jake wrote:

In message <[email protected]>, Kris
[screen readers]
Does that mean they do a horrible job at tabular data? I cannot imagine
that consumers would stick with such a program then. How would they be
able to read a timetable, for instance?

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.

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

Stopping accessibility is a priority 1 issue. A priority 2 issue is one that
makes it difficult to access.

Would you like to take that a bit further? I'm not sure what you're
saying ...........

 

[jake]

Not all tabular data is so straight forward - and even for a simplistic
example you provide, a screen reader user needs to backtrack.

Wouldn't most users want to stop and place their reader in 'tables
reading mode' so they could move around the table in their own time?

Now much
simpler would be to simply announce a table was encountered - that reduces
the barrier to access somewhat.

Except that on a tables-for-layout site, they'd hear 'something' when
they encountered any kind of table -- and presumably something else when
they reach a </table> tag.

As the screen reader couldn't tell the difference between a table for
data and a table for data, that's a lot of confusing verbiage (on many
sites) to wade through.

As -- what? -- 99% of the Web still uses tables for layout it would seem
to make sense (at present/the foreseeable future) not to announce tables
at all ... and leave it to the designer to have accessibility in mind
when presenting a data table (if considered necessary).

Something like:

<caption>Recent Society Publications <span class="hideit">A table of
publications with author and price information follows:
</span></caption>


Regards.

 

[jake]

jake wrote:

In message <[email protected]>, Isofarro
jake wrote:

In message <[email protected]>,
[screen readers]
Does that mean they do a horrible job at tabular data? I cannot
imagine that consumers would stick with such a program then. How would
they be able to read a timetable, for instance?

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.

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

Stopping accessibility is a priority 1 issue. A priority 2 issue is one
that makes it difficult to access.

Would you like to take that a bit further? I'm not sure what you're
saying ...........

http://www.w3.org/TR/WCAG10/#priorities

Sorry. Just not seeing your point.

I say that readers handle tabular data (very) well -- and you're reply
is to quote me the url of the W3C guidelines page.

Perhaps you make your point a little more obvious to a simple fellow
like myself ;-)

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.

More unsatisfactory assumptions.

Whatever ......

 

[WebcastMaker]

Stopping accessibility is a priority 1 issue...

Stopping accessibility or stopping in-accessibility (yes, I knew what
you meant) (0_o)

 

[Isofarro]

In message <[email protected]>, Isofarro
jake wrote:

In message <[email protected]>,
[screen readers]
Does that mean they do a horrible job at tabular data? I cannot
imagine that consumers would stick with such a program then. How would
they be able to read a timetable, for instance?

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.

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

Stopping accessibility is a priority 1 issue. A priority 2 issue is one
that makes it difficult to access.

Would you like to take that a bit further? I'm not sure what you're
saying ...........

http://www.w3.org/TR/WCAG10/#priorities

 

[Isofarro]

Sorry. Just not seeing your point.

Basic levels of accessibility account for removing barriers that make it
impossible for visitors to access content. This is a level A compliance
issue. Tackling these issues is a starting point for accessibility, not the
end.

The words you keep using "stopping accessibility" are merely signs of a
basic levels of accessibility. The inaccessibility of tables used for
layout is in the realm of "hindering accessibility".

I say that readers handle tabular data (very) well -- and you're reply
is to quote me the url of the W3C guidelines page.

The inability of a screen reader to distinguish a data table and a table
misused for layout forces that choice on the visitor. The visitor now has
to determine the result before the screen reader can render the content
acceptably. With basic tables this - according to your conclusion - is
straightforward.

I question that this remains simple when a visitor is faced with a more
complex tabular data - such as a financial report. Even a descriptive
feature comparision matrix may sound like a series of paragraphs in a
screen reader, so much so that the visitor doesn't have enough cues to
recognise the tabular nature of the data.

When the visitor has to second guess his own screen reader - that's a sign
of an accessibility issue with the content. Removing the cue of a table
element being present hinders the accessibility of tabular data.

 

[Isofarro]

Wouldn't most users want to stop and place their reader in 'tables
reading mode' so they could move around the table in their own time?

This only happens when a visitor believes the content to be tabular. That
belief would be based around receiving enough cues. Removing those cues
reduces the chances of the visitor switching to tables reading mode.

Except that on a tables-for-layout site, they'd hear 'something' when
they encountered any kind of table -- and presumably something else when
they reach a </table> tag.

As the screen reader couldn't tell the difference between a table for
data and a table for data, that's a lot of confusing verbiage (on many
sites) to wade through.

That "lot of confusing verbiage" is the accessibility problem - it hinders
the cue of tabular data by drowning it out in a sea of red herrings.

 

[jake]

This only happens when a visitor believes the content to be tabular.

Yes. But this is no different than using a CSS-layout based page unless
the reader announced tables.

That
belief would be based around receiving enough cues.

Yes. Again, this is no different than using a CSS-layout based page
unless the reader announced tables.

Removing those cues
reduces the chances of the visitor switching to tables reading mode.

And again.

That "lot of confusing verbiage" is the accessibility problem - it hinders
the cue of tabular data by drowning it out in a sea of red herrings.

But if the reader doesn't announce tables (your suggestion is that they
should), then there isn't "a lot of confusing verbiage", is there?

We mustn't lose sight of the fact that presently most of the WWW uses a
tables-based layout.

 

[jake]

Basic levels of accessibility account for removing barriers that make it
impossible for visitors to access content. This is a level A compliance
issue. Tackling these issues is a starting point for accessibility, not the
end.

The words you keep using "stopping accessibility"

When did I use these words?

are merely signs of a
basic levels of accessibility. The inaccessibility of tables used for
layout is in the realm of "hindering accessibility".


The inability of a screen reader to distinguish a data table and a table
misused for layout forces that choice on the visitor. The visitor now has
to determine the result before the screen reader can render the content
acceptably. With basic tables this - according to your conclusion - is
straightforward.

And you believe this not to be the case ...... why?

I question that this remains simple when a visitor is faced with a more
complex tabular data - such as a financial report. Even a descriptive
feature comparision matrix may sound like a series of paragraphs in a
screen reader, so much so that the visitor doesn't have enough cues to
recognise the tabular nature of the data.

When the visitor has to second guess his own screen reader - that's a sign
of an accessibility issue with the content. Removing the cue of a table
element being present hinders the accessibility of tabular data.

Interesting, but this doesn't change the fact that modern readers handle
tabular data (very) well.

You seem desperate to prove that visually-impaired folk can't tell when
they're working with a data table, and I'm really not quite sure why.

I have the impression that we're getting into a circular argument here,
so I think I'll take the question over to the accessibilty groups and
see what the word is from the people who (need to) use them everyday.

regards.

 

[Isofarro]

But if the reader doesn't announce tables (your suggestion is that they
should), then there isn't "a lot of confusing verbiage", is there?

This removes the cue that tabular data exists too. That is a problem.

We mustn't lose sight of the fact that presently most of the WWW uses a
tables-based layout.

Which is a major part of the problem. Too much noise drowning out the real
cues.

 

[Isofarro]

When did I use these words?

(e-mail address removed) - you use the words "But it doesn't
stop them from handling tabular data really well." which misses the point.

And you believe this not to be the case ...... why?

Simple tables is one thing, but your argument fails for textual tabular
data.

Interesting, but this doesn't change the fact that modern readers handle
tabular data (very) well.

_if_ a visitor knows or has cues that there is a tabular data there to begin
with! The world doesn't revolve around only simple data tables with obvious
cues. A moderately complicated table - especially those with plenty of text
- can be difficult to identify as tabular without the obvious "start of
table" cue.

You seem desperate to prove that visually-impaired folk can't tell when
they're working with a data table, and I'm really not quite sure why.

Perhaps you've not encountered anything other than a simple table with very
simple data?

 

[WebcastMaker]

Which is a major part of the problem. Too much noise drowning out the real
cues.

While the information (regardless of which) _may_ be harder for the
reader, bottom line is, that it IS accessible.

There are some layouts of web sites that I may find harder to read,
because of color, font, what ever, but the site is still accessible to
me, and I don't expect the owner to change because I find his method or
presentation a little more difficult for me. If I need the information
I can get it. I may not like the way they gave it to me, but they did
give it to me.

The same applies to those with special needs.

 

[Chris Morris]

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

Well, in practical terms, this should do it:
<table>
<caption>Table 3: Trout populations in 2002</caption>
....
</table>