replicating tables with CSS and Divs

[Tom]

Hi,

I have been told that using tables for layout is no longer advised, due to
accessibility considerations. Instead of tables, I should be using DIVs.

However, I was wondering how can I replicate the behaviour of various cells
on the same row, increasing in height at the same time and taking the height
of the biggest one.

I have three "cells":

+------------+ +---------------+ +--------------+
| | | | |
|
| | | | |
|
+------------+ +---------------+ +--------------+

I don't want one of the cell becoming higher than the other two when more
content is inserted:

+------------+ +---------------+ +--------------+
| | | | |
|
| | | | |
|
+------------+ | | +--------------+
| |
+---------------+

Thanks!

Tom

 

[Neal]

I have been told that using tables for layout is no longer advised, due
to
accessibility considerations. Instead of tables, I should be using DIVs.

Yes, but if the content is tabular - if each row and each column groups
and compares similar data - then table markup is fine, even appropriate.

However, I was wondering how can I replicate the behaviour of various
cells
on the same row, increasing in height at the same time and taking the
height
of the biggest one.

This gets a little tricky. You're expecting a div to size itself based on
a sibling div's content, which isn't how CSS works. Technically, this is
impossible. We'd need some way of asking the browser which of the 3
columns is rendered as tallest, and then going back and resetting the two
smaller heights to the larger value.

Here's a workaround, which unfortunately requires pixel-fixed widths. Use
a background image in the CSS for a container div which holds all 3 divs.
This image is 1 pixel high and as wide as all 3 columns, like this:
===+++=== Set it to repeat-y. It should continue to the bottom of the
parent div like so:

===+++===
===+++===
===+++===
===+++===
===+++===

.... giving the illusion of columns. (Be sure to include in the HTML some
real content within the container div but after the floated columns - use
a div set to clear. <div class="clear">&nbsp;</div> is what I usually use.

Another option allows for more flexibility in widths but relies on the
center column being the longest if there is a longest one. Here, use the
left and right borders of the center column as background foir the left
and right column, which are positioned over the borders, again creating
the illusion of columns.

Though, if this effect is required for usability, rather than simply
desired, the data might in fact be in such a relationship that it would
indeed be table data. In that case table markup would be appropriate for
these 3 columns.

Followups set to alt.html.

 

[Tom]

Neal,

thank you for the answer. It looks like not using tables will involve lots
of "tweaking"...

I must admit I am still a bit unclear about the W3C accessibility
guidelines: is it OK to use tables for layout or is it forbidden???

Tom

 

[Neal]

I must admit I am still a bit unclear about the W3C accessibility
guidelines: is it OK to use tables for layout or is it forbidden???

It is... up for interpretation.

Certainly if you accept the concept of semantic HTML - that the HTML code
should be solely used to describe the role of each part of the page,
rather than its appearance - table markup should only be applied in
situations where you have row and column relationships you want to compare
for the visitor.

Whether W3C makes this clear or not has been debated ad infinitum. Many
here, though, are proponents of semantic markup, and reserving all
presentational ideas to the CSS. Google for - "barry pearson" frames
group:comp.infosystems.www.authoring.html - for a pro-table layout
perspective.

 

[jake]

In message <[email protected]>, Tom

I must admit I am still a bit unclear about the W3C accessibility
guidelines: is it OK to use tables for layout or is it forbidden???

[snip]

Yes. It's fine -- so long as the content linearizes properly.

The W3C recommendation is to use CSS, but the W3C is also pragmatic
enough to realize that tables-based layouts will be with us for the
foreseeable future.

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

regards.

 

[Spartanicus]

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.

 

[Kris]

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.

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?

 

[jake]

In message

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

Nope

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.

Most modern talking browsers and screen readers handle tables (layout
and data) just fine.

Please tell me how you think the use of tables for layout gives a site
accessibility problems.

regards.

 

[jake]

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.

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.

Of course it helps if data tables are marked-up correctly (seemingly an
art or science that too many people are well versed in).


regards.

 

[Spartanicus]

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

Most modern talking browsers and screen readers handle tables (layout
and data) just fine.

Name one that announces the start of tabular content correctly whilst
staying silent on a table used for layout.

Please tell me how you think the use of tables for layout gives a site
accessibility problems.

I already did, try reading it again if you didn't understand it.

 

[jake]

In message

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

Most modern talking browsers and screen readers handle tables (layout
and data) just fine.

Name one that announces the start of tabular content correctly whilst
staying silent on a table used for layout.

None that I know of says 'Hey -- here's a data table'. But so what? How
does this affect accessibility?

I already did, try reading it again if you didn't understand it.

Give me the url of *one* page whose information content I cannot access
because they are using tables for layout.

Regards.

 

[Spartanicus]

None that I know of says 'Hey -- here's a data table'. But so what? How
does this affect accessibility?

If that isn't obvious to you, then I'm afraid it's beyond your ability
to understand.

Give me the url of *one* page whose information content I cannot access
because they are using tables for layout.

Oh dear, another case of the above. Against better judgement I'll try
anyway: accessibility does not end with the ability to access content.
It extends to providing coding that enables UAs to distinguish between
visual layout elements and tabular data without the introduction of
kludges that attempt to circumvent the problem you've created. Kludges
like that create new problems.

Your posts in alt.html.critique demonstrate that you have been able to
download a talking browser, the mistake you then made was to think that
therefore you understood accessibility, you don't.

 

[Neal]

Your posts in alt.html.critique demonstrate that you have been able to
download a talking browser, the mistake you then made was to think that
therefore you understood accessibility, you don't.

Having neither a talking browser nor the expertise in accessibility, I'd
sure like to see live examples of table layouts which screw up
accessibility for the talkies, and an explanation of why...

 

[jake]

In message

If that isn't obvious to you, then I'm afraid it's beyond your ability
to understand.

Stuck for an answer? Don't worry, I'll let you off this one -- as I can
see that to press the point would only be to embarrass you further.

Oh dear, another case of the above. Against better judgement I'll try
anyway: accessibility does not end with the ability to access content.
It extends to providing coding that enables UAs to distinguish between
visual layout elements and tabular data without the introduction of
kludges that attempt to circumvent the problem you've created. Kludges
like that create new problems.

Ah. Is that the best you can come up with?

You really must start getting together some proper arguments to
substantiate your statements.

(I'd ask you to explain these 'new problems' that the 'kludges' you talk
about create, but I fear that such an attempt to elicit something useful
from you would be doomed to failure.)

Your posts in alt.html.critique demonstrate that you have been able to
download a talking browser, the mistake you then made was to think that
therefore you understood accessibility, you don't.

I'll let the jury decide on that one ;-)Anyway. I can see that your knowledge on the subject is somewhat
limited, so sadly I don't think we're going to move this discussion
along much further. But if you ever do manage to figure out a coherent
argument as to how table-based layouts affect accessibility ... well,
don't be a stranger.

In the meanwhile, I have an idea. Why not contact the manufacturers of
the leading AT UAs and demand they take you on as a consultant? You
could explain that you obviously know more than they do ......

And then let me know how you get on ;-)

regards.

 

[Chris Morris]

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.

 

[Chris Morris]

Having neither a talking browser nor the expertise in accessibility,

30 day trial of IBM Home Page Reader is available. Definitely worth using.

I'd sure like to see live examples of table layouts which screw up
accessibility for the talkies, and an explanation of why...

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, but they can be a problem for others (see my
other post).

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.

 

[Spartanicus]

Having neither a talking browser nor the expertise in accessibility, I'd
sure like to see live examples of table layouts which screw up
accessibility for the talkies, and an explanation of why...

The most important objection against using tables for layout is that
they usually wreck content linearization. If you want a demonstration of
this then it's best to download an aural renderer. It's the best way to
get a feel for how linear one dimensional access to content differs from
2 dimensional visual access.

In some cases content linearization issues caused by using tables for
layout can be solved without having to ditch the layout tables. This is
typically done by using multiple tables, for example one table holds the
top navbar, another table holds a left side bar, yet another table holds
the content.

The statement I challenged was that there were no accessibility issues
with using tables for layout apart from content linearization.

Chunks of content like list items cannot be interpreted correctly unless
we mark them up as such. A UA is then able to display them in a
recognizable manner for visual access, or aurally announce the
structure. The way to do this for an aural renderer would be to speak
something like:

LIST
item 1
item 2
END LIST

It's no different for tabular content, users who access the content
aurally need to know before tabular content is read out that what is
about to follow *is* tabular data, thus an aural render *should* do
something like this:

TABLE
ROW 1
data
data
ROW 2
data
data
END TABLE

Doing this results in problems since a UA cannot possibly distinguish a
table used for layout from a table used to hold genuine tabular data.
That leaves 2 choices for the aural renderer:
1) Don't announce structural table elements.
2) Announce all structural table elements.

(1) Prevents aural users from being informed about, and interact with
tabular content (e.g. navigate table rows). (2) Confuses aural users by
announcing tables used for layout as tabular data.

A kludge for aural renderers that announce structural table elements is
to add something that may be rendered aurally by a UA that announces a
table used for layout by speaking something like "table used for
layout". This alerts aural users, but it doesn't prevent the pointless
reading out of the structural table elements of the tables used for
layout.

The current crop of aural UAs are really poor, not least because most of
them are speech agents tacked onto renderers like IE with deficient
support for css media rules. The popular IBM Home Page Reader (HPR) is
such an example.

Certain current aural UAs don't announce structural table elements at
all, nor do they provide table navigation. This has lead to the notion
amongst some that it therefore doesn't matter if tables are used for
layout, as long as the content linearizes. This is foolish, it presumes
that aural renderers will always be as poor as they are currently.

Content authors should mark up content so that it can be identified
correctly. Using tables for layout prevents that.

 

[Neal]

Certain current aural UAs don't announce structural table elements at
all, nor do they provide table navigation. This has lead to the notion
amongst some that it therefore doesn't matter if tables are used for
layout, as long as the content linearizes. This is foolish, it presumes
that aural renderers will always be as poor as they are currently.

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, why would authors change to
meet them? And if authors continue to use table markup presentationally,
why would UAs ever change? This catch-22 is a poser regarding the goal of
more semantic markup and more semantic UAs.

Short of more universally applied (and enforced) laws requiring pages to
demonstrate specific accessibility features which are best gained through
semantic markup, I can't see anyone changing soon.

 

[jake]

Having neither a talking browser nor the expertise in accessibility,
I'd sure like to see live examples of table layouts which screw up
accessibility for the talkies, and an explanation of why...

There really aren't any accessibility problems using tables for layout
providing that the tables linearize properly (as noted by W3C in their
Web Content Accessibility Guidelines).

In practice, linearization is rarely a problem, so you may have
difficulties in getting someone to give you some live examples ;-)

If you want to have some idea of the linearization process, just load a
Web page into Opera, set the Style to 'User mode' and then disable
Tables.

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 with ease,
assuming it's marked up correctly.

AT UAs (screen-readers, talking browsers, etc.) have now reached quite a
high level of sophistication (even if the general-purpose ones can be
rather expensive to buy) making the Web readily available to the
visually impaired, the dyslexic, etc..

Why not download a reader and see for your self?

regards.

 

[Neal]

Why not download a reader and see for your self?

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.