Chair: Jon Gunderson
Date: Wednesday, December 2nd
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: (+1) 617/258-7910
12:00-12:10 Update on scheduling of events with UA group
12:10-1:00 Discussion of table access issues and techniques
Chairs observation of the current table access techniques:
1. Simple linearization by removing table markup
2. Linearization based on table markup (i.e. if header information is available use it as a prefix to the data)
3. Linearization based on table markup with a "Point of Regard" to indicate a table and cell "focus". Point of regard would be maintained by the user agent and changed with through keyboard commands. Point of Regard would be used for cell navigation and can be used for inidcation to third party assistive technology on users focus. User would have a repair strategy of being able to select different types of rendering for poorly marked up tables based on the table with the current point of regaurd.
4. Explosing table information through the DOM and providing third party assistive technology with the ability to create their own point of reguard or manipulate the visual presentation based on the needs of their target population.
5. Propose future CSS and HTML standards that would allow for the generation of the table linearization and point of regaurd through these technologies
Issues to consider when evaluating techniques:
1. Complexity of programming (3rd party and UA)
2. Table nesting
3. Impact on disability populations
4. Use of W3C standards
5. Difficulty of developing a concise recommendation
6. Added complexity to current user interface (UA)
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Chair's Conclusions on today's discussion
Maybe some support in CSS2 for simple linearization.
CSS is primarily designed to operate on a specifc element and there is not a precidence to have a CSS spefication that would use other element information in the rendering of the current element. Therefore having header information inserted before a table cell data would be considered something that would take new thinking on the part of CSS working group. Although there is this exact specification for Aural Style sheets, so the topic would not be new to the CSS people.
DOM has a strucutred view of the table and would allow third party assistive technology to access the cell and header information. The UA would just need to support DOM and plateform conventions for external programatic access. This would provide 3rd party assistive technologies the maximum flexibility to integrate in keyboard access to not only tables but the rest of the elements in the document. The criticism of using only this approach is that all assistive technology vendors would need to replicate the work of table access and if linearization and navigation was built into the browser it would be available to all assistive technology developers. I think the group lacks information on how difficult this is for screen reader developers to implement (since many do not know of the existence of the DOM) and how this approach effects emerging XML applications. There are several options for the DOM approach:
Education of screen reader and other assistive technology developers about DOM
Provide example code to do table navigation and manipulation
It may provide a path to make XML applications accessible sooner, since XML apps will probably rely on DOM.
Need to take a closer look at Scott Luebkings table keyboard navigation model in context of embedded tables and overal keyboard navigation strategies. See E-mail message:http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0176.html
/* Discussion of End Game for Guidelines */
Denis: We should focus on guidelines document, making that stable. Other people may come up with brilliant techniques. Are we getting close?
Paul: I think we're getting pretty close. We have some things in general guidelines that we don't have in the techniques. But in general, I agree we are getting pretty close. I think we're trying to express better what we've already talked about rather than using our time to address new ideas. 1) Table linearization (See Jon's agenda)
Jon: One concern is that we don't have a complete and tidy solution. Also concerned that for mainstream browsers, we're trying to promote pseudo-support for speech output. Not sure that this is a good idea. How to use DOM and CSS as alternatives for improving access to tables/linearization.
Paul: Recently noticed on a Web site the same kind of problems as tables being created by layers. (Seem to be supported in some versions of both NN and IE). Could this also be handled with CSS or DOM?
Harvey: Do these DIV elements overlay?
Paul: Yes. Transparency depends on browser setting. With respect to screen readers, these overlays behave like tables (and pose same problems). When animated, screen reader didn't know how to handle.
Jon: Big issues: Table navigation Hiding/Showing parts of a table Context/Summary information
/* Discussion of 'visibility: collapse' in CSS2 */
/* Discussion of 'display: block' for table cells */
/* How would browsers support this? */
Harvey: Could use transformation part of XSL to accomplish the desired effect.
Ian: With 'display: block', you don't get header information, just a series of blocks.
Paul: You don't get navigation either.
Scott: What needs to be provided to understand the information in a table. For layout tables, relationships between cells often not important. For data tables, relationships are very important.
Scott: * "Layout table linearization": Unrolling a table so that blocks line up. * "Data table linearization": Require header info and navigation. Dealing with spanning information is more important.
Jon: Does CSS support header information (for data tables).
Harvey: HTML 4.0 header algorithm is flawed with respect to spanning issues.
Scott: If you're looking at a data table, you want to let users know when cells are empty intentionally.
Harvey: Differs from spans. Paul: Could we use THEAD/TFOOT to get single-cell rendering?
Scott: A panning feature is helpful, but don't want to limit users to single-cell viewing.
Jon: How about using DOM?
Scott: Difference between allowing access tech people to do something and forcing them.
Paul: What do you mean in practice?
/* Jon discusses Henter-Joyce use of interfaces to create structures more appropriate for screen readers */
Jon: I think that we need to
Paul: If I were a 3rd party assistive technology developer, how much infrastructure would I want to support just for Web-functionality accessibility.
Jon: Is DOM supported on other platforms than Intel?
Kathy: Probably, but not sure.
Jon: Need to ensure that linearization will make sense within larger UI context. Also, how do we deal with nested tables, for example? Not convinced we have a keyboard model for these cases that will fit neatly into the rest of the guidelines.
Scott: See my email about 'tN.rN.cN'. Nested tables work with table identifers. Identifiers at the beginning and end of each table.
Jon: Can people add cells/rows through the DOM?
Kathy and others: Think so.
Paul: If CSS and / or DOM will satisfy our needs, we shouldn't invent new ways to do something that developers will have to implement.