- From: <Ehansen7@aol.com>
- Date: Wed, 14 Apr 1999 11:26:54 EDT
- To: w3c-wai-gl@w3.org
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