Re: [wcag2] Layout tables

oedipus@hicom.net wrote:

>maurizio wrote, quote:
>Can anyone explain to me what kind of  handicap layout tables are for 
>people using website with any technology we can imagine?
>unquote
>
>it ain't a question of imagining, maurizio -- turn off your monitor, unplug your mouse, unplug your keyboard fire up voice-input and voice-output software and then you will be able to explain to everyone else who doesn't understand quote what kind of handicap unquote a uni-modal construct with exceedingly poor flow control such as a TABLE can impose, especially in the realm of ecommerce or news, or, better, yet, try and fill out a table-ized form -- even those which populate W3C space, whose layout is controlled by TABLE, lack such simple binding/orientational mechanisms as LABEL, FIELDSET, and LEGEND -- making anything other than the simplest 1 or 2 field form maddeningly difficult to complete, let alone submit with any sense of confidence that it has been completed correctly...
>  
>

no-no-no... wait a moment!... :)
We have to distinguish between simple table used to layout basic content 
(one unique, simple table that linearize well, no superflous nested 
tables, inside formatting with css, plenty of properly positioned 
internal skip to content link...) and old-fashion, visual-editor based 
nested and nested tables for layout. That makes a lot of difference.

You are talking of html pages that rely upon nested and unintelligible 
tables. I am talking about a transitional approach, that can save the 
baby when you put off the water. My experience is that blind users 
aren't hurted by simple table, and can easily navigate between the link 
and the content. The forms can be laid-out without the aim of tables, 
obviously.

A blind-user once told me: "No, layout tables aren't a problem for us, 
screen-readers can cope with them". This is probably not true if we have 
a perverse use of table. But this is a issue of abusing the tool, not a 
problem of the tool itself.

>if WCAG is to have any utility whatsoever, imagining has no place in our deliberations as a working group -- 
>

Well, I agree, even if sometimes it looks like some techniques are 
really imaginific, and lacks of real-life proofing... ;-) It's normal, I 
think, and I'm not blaming anyone for this: the WG made an incredible 
job, that only needs to be revised at the light of years passed by and 
real user-experience, to sound less "theoretical" in some aspects, and 
have major possibilities to be understood and applied by designers.

>what is needed is proof of concept, both from the markup point-of-view (and a thorough reworking of W3C space to bring it up to Level Triple-A compliance would be a good start) and from a testing point of view -- empirical evidence rather than addressing issues in theory is what is needed in addressing these issues -- quote if only assistive technology X implemented W3C TR Y, then the problem would be solved unquote is hardly the basis for providing quote real life unquote guidance...  there are more barriers to accessibility and more limits to the capacity of assistive technologies than are dreamed of in all our philosophies, so to base our conclusions and recommendations upon our limited knowledge slash imaginations is not only folly -- it is sheer madness...
>  
>

I think we should take into account a realistic set of assistive 
technologies. Accessibility are to encourage designers to use good 
practice, but assistive technologies often can vanify the good practices 
(I think about accesskey, in some cases), or make them superflous (I 
think about table/table-less design, i.e.).

To design without table should be encouraged, but, if that can't be 
achieved, we should point out that transitionally, a few well designed 
tables don't cause any problem to user - I can't see a case. We should 
encourage two options:
Opt. a, the best: Css pure layout everywhere it is possible.
Opt. b, absolutely put away the old-style multiple nested-tables for 
layout with bad semantic inside, and, if tables for some reasons are 
needed (i.e., backward visual compatibility), you *must* (and here not 
should...) use a simpler approach that use one simple table for overall 
layout and css for inside formatting. Only one level of simple nested 
table are allowed, and you must put inside jump to content (as you have 
to do in css based layout, after all). Use good markup inside the 'td' 
to mark appropriately the content.

In this way, no-one has an excuse to avoid accessibility. No backward 
compatibility cheating.

>when it comes to tables, remember, all of you with eyes to see, that there is NO such thing as a gestalt view for anyone processing information either linearly or in small discrete chunks...  tables, in particular layout tables, rely upon the brain's ability to construct a gestalt view via the agency of sight and the logical processing of symbolic markers (font weight, differences in background color, the visual order in which items appear, etc.) -- when one looks at a table, one is actually making a series of decisions as to the relative importance of discrete items, the proper flow of text, the relationship between non-textual elements and textual elements, etc. -- one can skip sidebars or read them in context or at a time of one's choosing -- without the gestalt view, such things are impossible, despite the best efforts of assistive technology developers and table-unrolling scripts -- what you see is very rarely what one hears or feels...
>  
>

Of course. But: the gestaltic view apply even to css-based design, for 
the ones that can see... The ones that uses sequential modality of 
access, can cope with no problem with simple tables, and very well if 
you have inside anchors and good internal markup.

>and for those who can see but who have difficulty processing too much information in too small a space or who cannot construct and/or maintain chains between related pieces of information because they are geographically separated, tables are equally pernicious...
>  
>

Also with the css... We are talking about equivalent visual design, but 
different tecniques to implement it.
Consider that very often the linearized version of css-based design 
(turned off css) are accessible, but sparingly usable and easy to 
understand. The relationship between pieces of content is conserved if 
you have a simple table, even if you turn off the css. I am not 
encouraging to use table, but we have to face some myths. Table are not 
really a problem, if well used: is it true? I think it is, and I'm 
asking for contributions.

>as for the oft-quoted quote reality unquote of clients demanding layout tables for backwards compatibility here's a counter-reality check: if the concern is quote graceful degradation unquote, then how can one justify the use of tables in the name of quote older browsers unquote when such quote older browsers unquote include table-incapable browsers, such as lynx and other text-based browsers...
>  
>

Well, if you compare the NN4 and IE4 market share with text-based 
browsers, there's no match.... ;-) Anyway, a simple table doesn't mean 
that text-based browser have troubles, as you know.

>if marquee and other such obscenities can be deprecated, derided, and suppressed, why not TABLE?
>

Because marquee and other obscenity add no values to the design, while 
table does. Tables can solve pratical problems without creating others. 
In some cases I found that complex layouts (mandatory for the client) 
are impossibile to achieve with pure css, even if we don't care about 
NN4... You all know that CSS can't subordinate the visual rendering of 
an element to the visual rendering of another element. In other words, 
we can't have a real grid-based design, but only a simulation (even if 
sometimes very complex). In some cases this means that no accessibility 
at all will be implemented in the project. If we encourage a simplified 
table-based design *only for the cases where there is no other good 
choice*, we rise the probability of accessibility being considered. Or, 
at least, we can blow up alibies.

>  all of the quote real world unquote and quote practical unquote objections to the use of layout tables strike me as spurious -- would the same people who complain that you didn't use tables on their web site because of backwards-compatibility issues also complain that you relied on a flash object to convey content?  javascript commands to reveal navigational options or to refresh content?  java applets and ActiveX controls?  no, of course not, and yet, the aforementioned often have difficulty (if not outright incompatibility issues) playing well with quote older browsers unquote, so the quote use tables for the sake of older browsers unquote argument simply doesn't hold water...
>  
>

Well, people are crazy. In Italy it's worth to see the kind of 
government we have--- ;-P
Ok, sorry, I'll never mention it anymore. :)
It's just to say that bad behaviors of designer doen't mean that some 
practice cannot be useful in real cases. Probably not in all the cases 
they claim it.

>slavery in the united states was long justified on the basis that quote too many people slash too much of the economy relied upon it for it to be abolished unquote as well on the basis that it is easier than performing the work oneself unquote -- the equivalent of the quote simpler coding unquote argument advanced in defense of layout tables...  all of the arguments which have been advanced for the preservation of tables as a structural element are equally spurious and indefensible...
>  
>

Nice comparison... slavery and layout tables... uhm... sorry, I haven't 
an argument for that. I have to pick the cotton balls in my master's 
garden, you see... :-))

>continued use of TABLEs for layout is no different than excusing the lack of an accessible entrance to a physical building simply because quote the developers didn't want to ruin the aesthetics of the facade unquote, or provide an accessible bathroom stall simply because it takes too much work, expense, and -- perish the thought -- forethought to install...
>  
>

There are two differences...
First, layout tables don't cause troubles in the real life, for what I 
can see, when properly used in a transitional approach. Not blame the 
tool, blame the abuse of the tool.
Second, layout table adds value to some (I think a minority) projects 
that cannot be achieved with css only. For the moment: so I call it 
*transitional approach*. I hope in 2010 we'll have some kind of 
grid-like property in CSS 3 or 4, and 7th generation browsers will be 
blowing in the wind, but, you know, I'm actually dreaming now.

My purpose is not advocacy towards tables, but preserving a good 
practice for using table-based layout when any other things can't obtain 
an acceptable result. I don't want the accessibility out of the window 
in those projects, not on the basis of myths, at least. Unless we can 
have a real problem using simple table, that I am not seeing here.

>either the WAI and GL takes a stand on issues such as this, our work is less than meaningless -- it is merely a sick, tasteless joke and a massive waste of the time and talent of all who have contributed to the effort, formally and informally...
>  
>

I'm sad you think so. I believed that discussing real-life accessibility 
problems, trying to see *if* there's an accessibility myth or 
misconception should be considered a contribution, not a waste of time, 
nor a sick.

Best things (and best intentions...)

Maurizio Boscarol
http://www.usabile.it/

Received on Monday, 19 April 2004 06:27:39 UTC