Minutes from W3C WAI UA Telecon 27 Jan 1999

Chair: Jon 
Scribe: Ian 
Judy Brewer 
Harvey Bingham
Scott Luebking
Charles McCathie-Neville 
Markku Hakkinen 
Daniel Dardailler 
Jim Allan
Kitch Barnicle 

Action Items and Resolutions
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:  
Cell data rendering [Prioiruty 1] 
Cell header information rendering [Priority 1] 
Cell positional information [Priority 2 or 3] 

1) Review of Jon's proposal about tables [1] [1]
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
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"
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
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:
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
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)
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.

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 Friday, 29 January 1999 11:17:56 UTC