Chair: Jon Gunderson
Date: Wednesday, February 3rd
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Proposal for checkpoints for rendering table elements
The following checkpoints are prosed based on last weeks telecon discusion on tables
Checkpoint 5.5.a [Priority 1] Allow users to navigate between cells of a table
Checkpoint 4.3.a [Priority 1] Allow the user to view one table cell at a time
Checkpoint 4.3.b [Priority 1] Allow the user to view header information associated with a cell
Checkpoint 4.3.c [Priority 2] Allow the user to view assumed headers associated with a cell
Checkpoint 4.3.f [Priority 2] Allow the user to view the summary attribute of a table
Checkpoint 4.3.d [Priority 2 or 3] Allow the user to view summary structural information about a table
Checkpoint 4.3.d [Priority 2 or 3] Allow the user to view element structural information associated with a cell
Checkpoint 4.3.e [Priority 3] Allow the user to view one table row or column at a time
Chair: Jon Gunderson
Scribe: Ian Jacobs
Kitch Barnicle
Harvey Bingham
Charles McCathie-Nevile
Jim Allan
Scott Leubking
Daniel Dardailler
Mark Novak (Trace Center)
Harvey Bingham, Mark Novak and Scott Leubking agreed to make a proposal by next wednesday on a algorithm for determining the headers of a table cell.
Jon Gunderson will develop a prosed recommendation for table conformance issues for AT
Announced a meeting is being arranged with the DOM working group on assistive technology using DOM.
Agenda/Announcement: http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0122.html
Assistive Technology Conformance related to Tables See proposal [1] from Jon: [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0120.html
/* Checkpoint 4.3.c [Priority 2] Allow the user to view assumed headers associated with a cell */
Ian: I propose that this be part of the table header algorithm. i.e., be merged with 4.3.b.
DD: I agree.
JG: 4.3.c is meant to be a repair strategy. As such should be separate from 4.3.b.
HB: This becomes an unbounded algorithm. There are too many ways to mix the pieces.
IJ: I think that repair strategies are techniques. Could tell user agent that if the HTML 4.0 algorithm doesn't work, here are a few suggestions. But too random to be a checkpoint.
JG: Do we want to allow the user to have input into the header algorithm?
SL: What kind of mistakes would occur? Is there a way to categorize them?
IJ: Ian reads the HTML 4.0 algorithm. The 'abbr' attribute is not addressed by this algorithm.
HB: This algorithm doesn't address how cells that span several rows/columns are handled.
IJ: Proposed: Start with the HTML 4.0 algorithm. If it's not adequate, fix it. But build everything in, including the worst case.
DD: My table linearizing tool doesn't deal with complex header information.
MN: The HTML 4.0 algorithm gives a good first-pass. I agree with Ian where we should However, you might add to this: the first row of a table is sometimes a span across the table. The *second row* contains the key header information. But for our needs, you may not want to delve in that far. I think it is helpful to the user to give them one additional try. But too many different options confuses them.
SL: I've played around with similar algorithms. I've looked for the first row that has as many cells as columns.
HB: Very often, cells in an earlier row will span several columns.
JA:
1) Do we recommend the use of the HTML 4.0 algorithm for "assumed headers" (or a better one).
2) Do we allow the user to choose other algorithms?
SL: Rather than talk algorithms, could the access technology provide a summary of first five rows/columns? This way, the user could choose which one contains header information. Or some combination of user choice + an algorithm.
HB: TH and column groups of HTML should be used to help this.
KB: Are we assuming that the user will be notified that there is no header and that it will be up to them to choose? Will the user know when the system is guessing?
JG: Authors may also misuse header markup.
KB: If a table is marked up correctly, the user can navigate and query for header information. If the markup is not there, we need to tell user that guessing is taking place.
JG: Would need to be able to turn on/off this feature.
SL: I've been playing with an algo for determining whether a table is for layout or data. A certain ratio of empty cells implies table as layout.
Action Harvey: Post difficult table cases to the list. Action Scott and Mark a) Examine HTML 4.0 algorithm (11.4.3) b) Propose an algorithm that mixes the auto algorithm with user interaction.
JG: Do we want to allow user interaction?
IJ: I think not Priority 1 but interesting possibility.
KB: If user has other navigation possibilities, user might be better off simply navigating table rather than experimenting with other options.
JA: I agree with that.
SL: I don't agree. It is difficult for users to interact with a table.
HB: Note the use of the word "view"
IJ: I have already proposed substituting "view" with "give access to"
/* Checkpoint 4.3.d [Priority 2] Allow the user to view the CAPTION element of a table */
/* Checkpoint 4.3.e [Priority 2] Allow the user to view the SUMMARY attribute of a table */
IJ: Don't need separate checkpoints for these since already covered in two places:
1) 6.1.1 : Support accessibility features of HTML.
2) Give access to alternative sources of information.
RESOLVED: Remove these two checkpoints
/* Checkpoint 4.3.g [Priority 2 or 3] Allow the user to view element structural information associated with a cell (Whoops: 4.3.g and 4.3.h are the same!) */
JG: Meant to say: you could find out how big a table is.
SL: Provide two levels of information: basic and detailed.
SL: I would include the option of having information rendered. Allow and "annotated" Web page.
IJ: I think this is an implementation issue. User needs useful information; there may be several ways to make that information available.
JG: Is summary information useful?
IJ: Having read lots of UA email, the theme of summary information comes up often (frames, page, tables, links, etc.) and would certainly be interesting in some cases.
KB: Being able to know where you are w.r.t. the sides of a table is useful.
JA: I agree. Calculated summary information is generally helpful. Students using Web Speak often hit the summary key. Gives them a better idea of what's there. Maybe Pri 2, but definitely a valuable piece of information. Not absolutely necessary to make the page accessible.
SL: I think it is. Depends on what you mean by "accessible information".
IJ: If not impossible without it, shouldn't be Priority 1.
RESOLUTION: No resolution about this proposed checkpoint
/* Checkpoint 4.3.h [Priority 3] Allow the user to view one table row or column at a time */
CMN: I think should be raised in priority since it allows the user to do manually what the header guessing algorithms are supposed to do.
HB: Why a whole column?
CMN: What's needed is the ability to navigate up/right/left/down from a given cell. Might be a technique. RESOLUTION: Put 4.3.h in techniques document. Related to navigation?
/* Announcement */
JG: I'm trying to organize a meeting with the DOM people. Will send an email to the list.
SL: Can we invite the president of ATIA (Assistive Technology Industry Association) to come to our teleconferences? We definitely need more AT developers on the calls.