Re: UA ISSUE OF THE WEEK: Table element access (fwd)

Sorry folks. This was a proposal I wrote before the telecon, but somehow
left the UA list off the recipients list :(. So here is the proposal that
I have talked about but kept secret...

I am changing the way I think about this slightly. Here are my thoughts,
followed by my proposals (which are adapted from Jon's):

TABLE should be used for tabular data. As a kludge, it is used to present
large amounts of data (like a whole page) in a particular spatial layout
in certain browsers. Although this is inappropriate, it is so common today
that any solution must address it as a serious legacy problem.

The goal is that the information in a TABLE should be accessible, and that
information is qualitatively different from information in paragraphs.

TABLE provides some metadata about relationships of pieces of information.

The normal way to access that metadata is to interpret the two-dimensional
layout as defining certain axes, so that anything on a given axis (eg one
row, or two columns) is related to everything else on the axis.

There are also mechanisms for specifying what the relationship is (eg a
header or headers such as TH can be used to explain that the relationship
is price of various objects.)

The type of objects might be a different axis, and there may be another
axis which contains all the information about a particular type of object.
(All this results from the fact that tables are not linear.)

So the user needs to have access to the structure of a table. Visually
this is merely a case of seeing it laid out, which is only a problem when
the available viewing window is smaller than the laid-out table. I don't
know enough about braille layout to be certain, but I would assume that it
has mechanisms for laying out tables. Again, the small size of most
brialle devices may introduce some complexity. Aurally, the problem is how
to linearise two-dimensional information.

So here are some proposals: 

(I have given checkpoints which are intended to be normative, and some
techniques which are intended to be informative, and could go in the
techniques document,)

Checkpoint 1:
Ensure that the extent of table cells can be determined by the user

techniques:
Visual/tactile: 1.1 render the table with a spatial layout or explicit
markers [P1]

Aural/haptic: 1.2 identify cell boundaries explicitly [P1]

1.3 When the content of a cell is another table, alert the user. [P1]

Interface: 1.4 provide an interface which gives access to the underlying
content (either DOM, or HTML so it can be re-parsed) [P1]


Checkpoint 2:
Provide access to the header information associated with each cell

techniques:
visual/tactile: 2.1 Present TH in a distincitve manner [P2]

aural/haptic: 2.2 implement the 'speak-headers' property of CSS2 [P2]

Interface: 2.3 provide an interface which gives access to the underlying
content (either DOM, or HTML so it can be re-parsed) [P2]

Checkpoint 3:
Provide access to summary information for a table

(This depends on the user interface, but seems obvious enough that I
don't propose specific techniques)

Checkpoint 4:
Allow the user to navigate the structure of a table

techniques:
visual/tactile: 4.1 Ensure that the spatial layout can be traversed (eg by
scrolling) [P1]

4.2 provide a 'scroll lock' option, so that a table can be scrolled while
the headers remain static [P3] (for most single-line braille displays this
will not be possible without significant AT programming)

Aural/haptic: 4.3 allow the user to read the table by row and by column
[P1]

4.4 provide the user with a means to identify and navigate nested tabel
structures [P 1?2]

I have left out the Checkpoint Jon had about being able to serach for text
within a table, largely becuase it is not quite clear to me. Do you mean
search only within a table (analagous to search selection) or ensure that
searches include data in individual tables (which I would put in any
guidelines we have about searching, rather than tables)

Thoughts?

--Charles McCathieNevile -  mailto:charles@w3.org
phone: * +1 (617) 258 0992 *  http://purl.oclc.org/net/charles
W3C Web Accessibility Initiative -  http://www.w3.org/WAI
545 Technology sq., Cambridge MA, USA

Received on Wednesday, 13 January 1999 15:27:48 UTC