W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 1999

Re: Proposed change to checkpoint 5.3

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Thu, 15 Apr 1999 09:22:31 +1000 (AEST)
To: WAI Markup Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.SUN.3.95.990415082937.7779B-100000@ariel.ucs.unimelb.EDU.AU>
There are several difficulties with Ian's thought provoking proposal.

1. It can not have a priority 1 rating, as the definition of priority
level 1 is not satisfied. It is always possible, albeit impracticable, for
a reader mentally to bring together disparate fragments of content to
reconstruct the document. This can, admittedly, be a challenging and time
consuming task, but it is possible and therefore precludes any
table-related checkpoint from being a priority 1 access barrier.

2. There are several problems associated with layout tables. (1) The need
to provide an appropriate reading order. (2) The inability of conventional
screen readers to handle columnar material well; this is addressed in
checkpoint 10.6. (3) Loss of structure (and hence loss of formatting when
the document is transformed into different media, with or without style
sheets) (further elaboration shall be given below). (4) The need to
distinguish layout and data tables (this can be largely accomplished by
assuming that any table containing only td elements is not a genuine data
table). (5)The fact that layout tables are a serious abuse of TABLE markup
and that CSS positioning provides a more effective and medium independent

3. Point 1 can be addressed through linearisation techniques, so long as
the document is marked up in such a way as to provide a reasonable reading
order when the table-related elements are removed.

4. If the table produces only a single column of text, alternative pages
can be avoided, thus reducing reliance on guideline 10.6.

5. Point (3) raises a central access concern which would need to be
overcome before I could, in good conscience, agree to any removal of the
priority 2 injunction against using tables for layout. A fundamental
premise of the guidelines is that a document is minimally accessible
(thereby warranting an A rating, at the lowest threshhold of
accessibility) if its content is readable, in the sense of being sensorily
perceptible, irrespective of the output medium. If a "double-A" rating is
achieved, there must be no significant barriers to accessing the document.
Consequently, it must be more than merely readable; its logical structure
and the semantic distinctions which the author intended to convey by means
of formatting conventions, must be represented in the user's output
medium. There are, of course, other requirements regarding comprehension
and navigation which are not adequately taken into account in this
analysis, but even so, it suffices for purposes of the present discussion.

The requirement at a priority 2 level that the structure and semantic
distinctions communicated by formatting devices in the document be
presented effectively in the output medium, implies, in the case of audio
and braille output for example, that appropriate braille formatting or
auditory cues be given that represent the distinctions that would be
conveyed visually through font changes, text positioning, etc. Now if
tables are used in place of more structurally-oriented markup, as is often
the case, the ability to preserve this formatting is lost. More
concretely, if a document is represented as an array of table cells,
rather than in terms of headings, lists, paragraphs, (correctly employed)
block quotations, etc., the structural distinctions that would properly be
represented by the latter elements would be lost. A centred or right
justified data cell might, in a visual context, represent a heading, but,
there being no HTML heading [H1...H6] element present, this important
structural feature will not be represented appropriately when the document
is transformed into different media, even if the table-related markup is
removed. Other examples could be cited, but in the context of this working
group I feel no need to stress the point.

In the case of the W3C home page, the table markup is not being used in
place of structural elements. The lists and paragraphs comprising the
document are, in part, contained within the table markup, and thus a
reasonably well structured document would result if the table-related
markup were simply stripped. In many cases however, this is not so. If a
document is largely formatted with layout tables, its structure can not be
easily recovered, if at all. To take a further illustration: when
linearising, should the table-related elements be turned into paragraphs
or simply deleted? In the case of the W3C home page, the paragraphs are
explicitly given, so in this case one would not wish to replace <TD> with
<P> but naturally, this would not be true in all cases.

Essentially, my argument is that layout tables could only be regarded as
priority 2 accessible if the logical structure of the document (headings,
paragraphs, lists, block quotations, etc.), would be properly and
accurately preserved if the table-related elements were simply deleted.
Otherwise, there is a net loss of structure, which means that the
distinctions that are intended to be communicated by formatting would be
obliterated in the transformation to a non-visual medium, and that a
priority 2 rating would not be justified.

In conclusion therefore, it might be reasonable to permit a priority 2
rating where the table-related elements are not acting as substitutes for
more structurally appropriate markup (or, stated differently, where
removing the table-related elements would yield a properly structured
document). Any solution which degrades logical structure and semantics is
deeply problematic, for these are essential to the level of accessibility
defined by the "double-A" rating and, more importantly, to the notion of a
document's being genuinely medium independent -- capable of being
rendered, with its structure and semantic distinctions intact, in a
variety of media, including braille and audio.
Received on Wednesday, 14 April 1999 19:22:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:59:08 UTC