Re: Proposed change to checkpoint 5.3

It should also be remembered that the priorities and checkpoints are based
on what is needed for access (at different levels of accessibility), and
that convenience or otherwise for content developers is not a relevant
consideration except in so far as a choice needs to be made between two or
more strategies that are equally advantageous from the standpoint of
access, but which can not be implemented with equal ease or convenience,
in which case the the more practicable solution is to be preferred.

Thus, questions pertaining to the likely effect of guidelines concerned
with tables on developer acceptance of the guidelines should not influence
the decisions of the working group, which must be made on principled
grounds, based on the definitions of priorities as given in the document
itself and also on the access barriers which layout tables create. This is
why there is a rather strictly defined set of circumstances in which
layout tables can be used, without requiring generation of an alternative,
structurally and semantically rich, version of the document, namely those
conditions under which the structure and content are adequately reflected
in the markup and the tables are not acting as a substitute for other
markup constructs, but only as a kludge to force a particular rendering by
visual user agents. By avoiding TH, CAPTION, and other such elements in
layout tables, a user agent can distinguish between layout and data
tables. Furthermore, the single column requirement avoids problems in
respect of primitive screen readers (I might be wrong of course, but it
still seems to me that there would be a significant constituency of screen
reader users who would find multi-column tables problematic without the
wide availability of linearisation software).

A formulation similar to the following might be appropriate (comments are
welcome):

"5.3: Avoid using tables for layout unless the required formatting effects
can not be achieved with style language features supported by user agents.
(Priority 2).

[Note discussing the evolution of style sheet positioning and the
anticipated implementation of this capability by user agents, and pointing
out that layout tables constitute an abuse of HTML markup as defined in
W3C Recommendations on HTML.]

5.4 If tables are used for layout, (a) do not use TH cells to produce
special font effects; this will also enable screen readers, braille or
speech-based browsers, etc., to distinguish layout tables from those which
contain genuine tabular information. (b) Ensure that within the table
cells, correct markup is used to convey the structure of the document
(including headings, paragraphs, lists, etc.), and that an appropriate
reading order would be preserved if the table were linearized. See also
checkpoints 3.2, 3.3 and 3.4.

Priority 2

Note: Some screen readers can not decolumnize tables. It is therefore
necessary to avoid the use of layout tables, or provide an alternative
page, if a multi-column format is desired. See checkpoint 10.3."

In the glossary, definition of linearization as applied to tables:
ignoring table-related markup, etc.

Received on Friday, 16 April 1999 00:12:42 UTC