Re: Tables Accessibility - Heredity

  From: Harvey Bingham <hbingham@ACM.org>
  Subject: Tables Accessibility

[big snip]

  The axes of these layout tables is "ancestry" that may or may 
  not need to contribute to the global axes information for the 
  cell in which there is a "data" table. The issue is similar if 
  frames are used for different tiled regions: should the frame 
  identification be part of the ancestry. 

Al, here...

The objective of any short-term reforms for tables should simply
be to get the relationships straight between content and the
descriptors that pertain to the content.

Typical content is what is in a TD cell in an HTML 3.2 TABLE
construct.  One should be able to unambiguously determine what
the user is supposted to understand about this content from the
context created by the Table.  Typically, the contextual
information is provided by TH cells at row and column heads,
Table titles, and the first mention of the table in the
accompanying text.  

The problem that you correctly pointed out in current TABLE usage
is that when a TH element appears in the interior of a table, it
is not clear whether it describes TD cells below it or to its
right, and it is not clear whether it refines or supercedes TH
information above and to the left of it.

Here I am talking about what we need to ask from server-side
activities, particularly Web page authors and tools, in order
that client-side activities can present the information
competently for those with and without vision.  The path to
Mike's transparent access lies through competing invention on
the client side but the client side can't get anywhere unless
what the server side does supplies sufficient resources.
If the content on the server is not access-compatible, there
is no way the client-side tools can make the information
accessible.

As you pointed out, HTML 3.2 only captures enough information
about the table contents to lay it out for visual communication.
The communication of which TH elements apply to which TD elements
depends on things that the reader will know, but are outside of
the knowledge of the formal HTML encoding.

If the practices at the content-sourcing end are reformed so that
you can determine without a doubt what a TH pertains to, and what
descriptors pertain to a TD, you will have given the client
software builders the resources they need to build a dialog with
the human user that works.

An yes, if the table is in a frame or a cell contains a frame,
frames are part of the context hierarchy that must be retrievable
from any point in the browse.  But that is there now.  You know
what frame the table is in.  You don't need to encode this in any
new metadata.  The client software can construct the stack of
descriptors that goes with the contexts as it parses the HTML.
What we don't presently know is if the TH is in the interior,
does it govern TD cells to its right or below it?

We need to be able to construct the "focus" entities that Jim
spoke of.  One such focus is a TH and all the TDs or sub-tables
to which it applies.

If we costruct foci bottom-up in this way, then "layout tables"
are supported as well as simpler structures which contain just
one completely regular relation.

--
Al Gilman

Received on Sunday, 4 May 1997 10:44:43 UTC