- From: Al Gilman <asgilman@access.digex.net>
- Date: Sun, 4 May 1997 10:42:02 -0400 (EDT)
- To: dev-access@world.std.com, w3c-wai-wg@w3.org
- Cc: w3c-wai-wg@w3.org
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