Tables for Layout

Tables for Layout

I think that checkpoint 5.3 should be deleted. It reads:

"5.3 Avoid using tables for layout. [Priority 2]"

On the surface, it may seem a very appropriate checkpoint, at least to people 
(like myself) who have witnessed the difficulty people who are encounter in 
trying to access certain tables. 

Yet there are several reasons why the Working Group should consider deleting 
this.

First, there is no way to lay out elements on a screen that can replace the 
layout capability of tables - especially with the same ease and control 
provided by tables. (I rely partially on information from the last phone call 
for this observation.) Frames might be used, but they also have a number of 
accessibility problems. One would like to use CSS, but it appears that CSS3 
(or some higher version) would be required for proper rendering of certain 
kinds of tables. Yet browser support even for CSS1 is currently inadequate. 
In my opinion, no checkpoint should be included if it is believed to be 
extremely impractical or infeasible. 

Second, the necessary accommodations are already provided by checkpoint 10.3. 
It reads:

"10.3 Until user agents or assistive technologies render side-by-side text 
correctly, provide a linear text alternative (on the current page or some 
other) for all tables that lay out text in parallel, word-wrapped columns. 
[Priority 2] 
"Note. This checkpoint benefits people with user agents (such as some screen 
readers) that are unable to handle blocks of text presented side-by-side; the 
checkpoint should not discourage content developers from using tables to 
represent tabular information."

As was noted in a phone conversation yesterday, this Priority 2 requirement 
for a linear text alternative covers both tables for layout and tables for 
data. The linear text alternative should ensure that the table is accessible.

Third, as written, checkpoint 5.3 seems too broad and ignores cases in which 
tables for layout may be just fine. I have seen a table used for layout that 
contained what I believe was a screen-reader-friendly navigation bar. The 
table was simple, using one row and no word-wrap. To the best of my 
knowledge, it would not cause an accessibility problem for speech or braille 
output. Yet if I understand checkpoint 5.3 correctly, a page or site that 
contained such a navigation bar could obtain no better than a single-A 
conformance rating unless an alternative page were also provided..

Fourth, the negative requirement ("Don't do Y") is likely to seem an unfair 
incursion upon a preferred presentation method of a large group (i.e,. 
individuals without disabilities). It is often fine to say,  "Do X to make 
the content accessible for people with disabilities", yet one should be very 
careful about saying "Don't do Y" especially when huge numbers of people find 
doing Y useful. This may seem especially unfair if one is already providing 
an alternative for people with disabilities (per checkpoint 10.3).  If one is 
already providing a text equivalent for the table (in the sense of being able 
to use a linearized alternative to fulfill the communication function of the 
table in synthesized speech, braille, or visually-displayed text)  per 
checkpoint 10.3, then Web developers should not be restricted from using 
tables for layout.

Recommendation:

My recommendation is to delete checkpoint 5.3. In my view it is not a 
feasible, practical checkpoint. And it is not essential.

Perhaps it is appropriate to encourage people to avoid tables for layout, but 
this should be done in a "Note" rather than in a checkpoint, perhaps on the 
model of the note regarding avoiding "alternative pages" located at the end 
of guideline 11. A page or a site should be able to use tables for layout and 
still obtain a double-A or triple-A conformance rating, 

Personally, I think that this change could significantly improve Web 
developer's acceptance of the guidelines. It is easy for people to understand 
why they need to provide a text equivalent for audio and video, but they will 
have a harder time understanding why they should avoid using 
tables-for-layout, even when the table merely includes "text", which is 
supposed to be accessible. Web developers who seek to adhere to the 
guidelines at the Priority 2 level will already be providing a text 
equivalent of the tables. Let's not hit them with another Priority 2 
checkpoint that prohibits tables for layout.

====

Eric G. Hansen
Development Scientist
Educational Testing Service

Received on Wednesday, 14 April 1999 11:29:51 UTC