Re: operational concept for table browsing

On Sat, 4 Oct 1997, Al Gilman wrote:

> My current rough take on the situation is that there is inadequate
> support for the "keys" kind of relationship as discussed in 
> 
>    more on TABLEs
> 
>    http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0004.html
> 
> and that it's worth defining default rules and explicit markup to
> support both this and its companion "is-a" kind of relationship
> that I suspect is covered sufficiently with AXIS and AXES.  The
> defaults can be made more effective if we have predefined class
> names for row-major, column-major, etc. classes of tables.
> 
In connection with the first point, it seems that Al is concerned
primarily with the means by which the relationships between cells are
established. Though I do not claim fully to understand his profound
thinking in this area, I shall nonetheless make a few tentative comments
which Al can undoubtedly correct in the event that I am mistaken as to his
intention. One can start with the premise that not only header cells, but
also data cells can comprise that which may be called the subject matter
of a given data cell. In one of the examples provided in the September
draft ("Cups of coffee consumed by each senator"), the second and
subsequent cells in each row of data are linked not only to their
corresponding column headers, but also to the first column of data cells
(which give the names of the senators). This relationship is represented
visually by the fact that all of the cells are in the same row and the
implications which can be drawn from the column headings. Thus, the second
and subsequent columns of the table are implicitly linked to the first
column as well as to the column headers. Is this the kind of relationship
that Al wishes to capture? If so, then such interconnections can be
expressed by modifying the definition of the AXES attribute so that the
target ID values can be data cells, as well as headers. Indeed, this is
the concept which I think underlies the inadequately explicated idea of a
"row header", which is mentioned in the HTML draft. Nevertheless, as Al
also appears to be arguing, it would be preferable to be able to define
such relationships by means of rules rather than relying on the author to
include an ID value and corresponding AXES attributes in each row of the
table.

Al's second point, namely the need to indicate whether a table is row or
column dominant, brings us back to considering the problem of reading
order. If style properties, such as those which I have previously
suggested, are used to regulate the reading order, then a mechanism for
indicating row or column dominance is clearly superfluous. However, most
authors are not likely to define styles for controlling the audio
presentation of their tables, in which case, a default reading order
(whether to read across the rows or down the columns) should be specified;
and as Al rightly points out, this can be achieved by reserving
appropriate CLASS values.

Returning briefly to the issue of inter-cell relationships, it is clear
that for a simple table (such as the "coffee consumption" table in the
HTML draft), an ideal audio rendering can be given without the user
agent's having to take into account the role of the first column as
defining the subject matter to which the remaining columns refer. One
would not, for example, wish the senator's name to be repeated prior to
each of the other cells in the given data row. The audio rendering stated
in the HTML draft is quite adequate. Are there more complex cases,
however, in which the relationships between data cells are more
significant and would need to be specified in the markup in order for a
satisfactory audio presentation to be possible?

I must admit that I find the expense account table mentioned in the HTML
draft to be somewhat difficult to understand merely from reading the
markup, and that the associated image of the table is of course
inaccessible.

Received on Sunday, 5 October 1997 19:58:00 UTC