Chair: Jon Gunderson
Date: Wednesday, January 27th
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Checkpoints for conformance for graphical desktop user agents and assistive technologies related to the accessible rendering of table information.
The long term strategy for compatibility with assistive technology is exposing the DOM to 3rd party assistive technology and a priority 1.
Jon: Send resolution notice to list
Jon: Contact DOM working group for coordination
Proposed 6.2.7 [Priority 1] "Provide a means for the user to execute a script at the end of loading (onload event in HTML 4.0 specification) and document changed (may not be defined in current W3C standards) events" was discussed, but there was not support for the inclusion of the checkpoint as stated. A checkpoint that would include this type of feature should be stated as a problem with this a technique for solving the problem.
Checkpoint 4.3.1 [Priority 1] "Allow the user to view one table cell at a time with associated header information" was generally agreed that this was a good checkpoint with editorial style changes. It was suggested that the checkpoint be exapnded to 3 checkpoints that would address:
1) Review of Jon's proposal about tables   http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0073.html
a) Checkpoint 6.1.4 [Priority 1] Fully implement the Document Object Model Level 1
CM: Checkpoint 6.2.6 and 6.1.4 are tightly bound.
IJ: DOM doesn't talk about interprocess communication. Has to be exposed.
What to use to expose it?
COM on Windows?
What about other platforms?
Scott: I think we should combine 6.2.6 and 6.1.4 or cross-reference them at least.
JB: Ensure that checkpoints, even if they are specific to either user agents or assistive technologies, remain general enough for other user agents.
HB: About Checkpoint 6.1.4.
What does "Fully implement" mean?
b) Checkpoint 6.2.7: [Priority 1]
IJ: I don't agree with this one. This is an implementation issue.
SL: "script" is too general, too open.
CMN: I like this idea.
What you seem to be after is an "interface trigger".
I would define the user's hand-written script as a kind of "assistive" technology.
SL: What is the syntax of the script?
Who is responsible for interpreting it?
Can't force support for multiple scripting languages.
IJ: - Defining "onload" behavior outside of the HTML WG is a no-no. - CSS WG is working on action sheets, which is what you want. The UA WG should not be doing this work.
JB: We need to define a dependency with the CSS WG on this issue.
SL: Could the checkpoint refer to the CSS Working Draft on this topic.
IJ: - I think 6.2.7 is a solution. What's the problem?
CMN: Event notification is part of the DOM.
CMN: A piece of the checkpoint is still interesting...
JG: Which part?
CMN: Allowing another script or program to know when something has change: even notification. This is already a checkpoint, in fact. I think 6.2.7 is a particular solution, not necessarily the right one, and it's constraining.
Resolved: 6.2.7 in its pesent form is does not have wide spead support for vaious reasons, this type of functionality though maybe useful but needs futher refinement for possible inclusion .
SL: Add a note to the techniques document so that developers are aware of this issue: user-specified scripts.
Checkpoint 4.3.1 [Priority 1] Allow the user to view one table cell at a time with associated header information
IJ: Change "view" to "give access to".
SL: I think access must be easy.
CMN: I'd like to split the "associated header info" into a second checkpoint.
HB: I agree. Users may have a variety of header information and which they choose is up to them.
SL: Sounds like different "aux" information about a cell: a) contents b) header c) position, span information CMN and SL think that (c) is a Priority 1.
SL: What additional "rendering" are we going to require of graphical user agents. See my postings on this topic (e.g., table linearization).
/* Discussion about what UAs should have to do natively */
JG: I think linearization is not a full solution.
SL: If we had AT developers signing up and claiming responsibility, I wouldn't come back to this point as often.
JB: a) If you're trying to reach consensus on this, any proposal the Chair makes must be documented.
b) There may be some points where there is not unanimity. Minority points must be documented.
Action JG: Draft a proposal to solve this issue.