W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1998

Minutes and conclusions for telecon on Wed, December 2nd

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Wed, 02 Dec 1998 16:41:36 -0600
Message-Id: <199812022240.QAA19134@staff1.cso.uiuc.edu>
To: w3c-wai-ua@w3.org
WAI UA Telecon for December 2nd, 1998 

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
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

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)
Paul Adelson 
Harvey Bingham 
Scott Luebking 
Denis Anson 
Kathy Hewitt

Action Items and Conclusions

Chair's Conclusions on today's discussion

CSS for linearization:
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
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

DOM for Linearization
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:

1. Education of screen reader and other assistive technology developers about

2. Provide example code to do table navigation and manipulation 

3. It may provide a path to make XML applications accessible sooner, since XML
apps will probably rely on DOM. 

Keyboard Models for Table Navigation
Need to take a closer look at Scott Luebkings table keyboard navigation model
in context of embedded tables and overal keyboard navigation strategies. See

/* Discussion of End Game for Guidelines */ 
Denis: We should focus on guidelines document, making that stable. Other
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
getting pretty close. I think we're trying to express better what we've
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
Ian: With 'display: block', you don't get header information, just a series of
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
are empty intentionally. 
Harvey: Differs from spans. Paul: Could we use THEAD/TFOOT to get single-cell
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
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
Scott: See my email about 'tN.rN.cN'. Nested tables work with table
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.

Copyright  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,
trademark, document use and software licensing rules apply. Your interactions
with this site are in accordance with our public and Member privacy

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
Received on Wednesday, 2 December 1998 17:40:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC