Chair: Jon Gunderson
Date: Thursday, Feburary 3rd
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
David Poehlman
Harvey Bingham
Rich Schwerdtfeger
Mickey Quenzer
Dick Brown
Gregory J. Rosmaita
Kitch Barnicle
Denis Anson
Regrets:
Marja-Riitta Koivunen
Charles McCathieNevile
Jim Allan
Regrets: Ian, Marja
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0231.html
1.IJ: For 4.10 add the CSS2 property. And cross reference 4.7 techniques
Status: Not done
2.IJ: For 4.11 add the CSS2 property.
Status: Not done
3.IJ: XWindows techniques for 5.3
Status: Not done
4.IJ: DOM2 techniques for 5.3 (if any)
Status: Not done
5.IJ: For 6.2 add a link to the TR page. Add links to conformance sections
in specs. Also to validation services.
Status: Not done
6.IJ: Fix section numbering in techs doc in checkpoint 7.3
Status: Not done
7.IJ: Ensure that checkpoints are in proper priority order.
Status: Not done
Status: Not done.
8.JG: for 5.3: Find out windows/mac accessibility guidelines.
Status: Not done.
9.JG: Send a list of questions related to AT developers to the ua list.
Status: Done.
10.JG: Add discussion to next weeks agenda of how techniques are added to
technique document.
Status: Done.
11.CMN: Follow up on this with some learning disability people on graphical
configuration issue .
Status: Cancelled.
12.DA: For 2.4, link to markup language specs where text equivalent info is
discussed. Include rationale. Point to WCAG 1.0
Status: Not done.
13.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Status: Pending
14.DP: Send comments related to accessibility problems of IE 5.5 beta to
the UA list.
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0207.html
DB followup:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0208.html
15.DP: For 4.7. Note that setting the volume is different than configuring.
Submit technique.
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0219.html
16.GR: Send to the list techniques for how to use and control focus to not
have new windows cause problems for usability. In particular, how this will
work with ATs.
Status: not done.
17.JA: Submit techniques for 4.14
Status: No info.
18.JA: For 4.8 check with Geoff Freed and Madeleine Rothberg, and copy
response to Marja any results.
Status: No info.
19.JA: 4.14: There are CSS2 properties (including :focus).
Status: No info.
20.MK: For 4.8 check if any media players do this?
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0242.html
21.MK: Find out techniques for sending text search requests to servers of
streamed text.
Status: No info.
22.MR: Review techniques for topic 3.1 (Multi-media)
status: no info
23.MR: Review techniques for Guideline 4 (Multi-media)
status: no info
24.MR: Run a multimedia player through the guidelines for January.
Done: refer to
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0253.html
25.MQ: For 4.9. Send a screen shot.
Sent cancel message.
26.MQ: Ask Mark about meaning of comment raised in Issue #167
Status: pending.
27.MQ: Ask Mark Hakkinen about telephone browsers and the guidelines.
Status: pending.
JG: List of people contacted on the home page.
IJ: After CR closes, need to compile info. CR review comments may have an impact on the document.
JG: Propose adding a meeting the 23 Feb to handle CR comments.
Action JG: Send request for times to adminreq.
JG: The ball's in Judy's court. Dates are those discussed for April.
JG: Out of discussions with Charles at Microsoft. Question of how to verify timeliness.
Checkpoint 5.5 in Candidate Rec [2].
[2] http://www.w3.org/TR/2000/CR-UAAG10-20000128
IJ: What does "timely" mean?
JG: What do we mean by this checkpoint?
RS: Where this originated - in Windows, they want you to use the COM. Since you can only do this from another process, you are affected by system scheduling priorities. Access is then slow. We found in tests that in-process response times were 12 times faster.
DA: The AT user should have the same experience.
RS: Want no noticeable degradation in performance.
DA: In Word 97 (Win98), virtual keyboard input much slower than physical keyboard input.
JG: So "timely" has do to with process scheduling.
JG: The other issue is synchronization.
RS: You can't assume synchronization with fast APIs. Suppose that while the AT is traversing the DOM tree, if the location in memory is deleted, or the element members are distorted, accessing those memory locations could lead to a crash. This is a separate issue.
DP: An example of timeliness: an AT starts rendering *before* a new page is loaded.
DA: That's part of the proposed handshaking technique.
JG: Apparently you can't start traversing the tree until the load complete event received.
JG: Is timeliness separate from the synch issue?
RS: I don't think the two should be mixed. Some locking mechanisms may be necessary to prevent corruption, etc.
JG: Glen Gordon has complained about the MS because of out-of-process access. They developed their own since they could do so in process.
RS: Semaphore interface necessary when running on a separate thread. That may be part of a WAI PF requirement for DOM 3.
GR: I had proposed a checkpoint based on a WAI PF discussion. I'll post the proposal to the PF list as part of our DOM 3 wish list.
IJ: I don't think it's reasonable to require a semaphore interface on user agents.
/* Return to verification of "timeliness" in 5.5 */
DB: I should consult Rob Sinclair (at MS, does MSAA) on this.
RS: I've sent email to him.
RS: The "helper" facility from IE is one technique for being in-process. Another is to embed the browser in your application.
RS: I'd like to see "in-process" happen. It would take significant changes to MSAA to make that happen.
IJ: I think that if in-process is required, the problem of no standard for access to the DOM falls away.
IJ: I propose asking PF two questions:
- Should we change "timely" to "in-process"?
- What kind of synchronization necessary?
Need feedback by 18 Feb.
Action RS: Take these issues to WAI PF. Get input from MSAA developers as well. Craft email to PF WG with Ian.
IJ: I spoke with Håkon Lie about the DOM requirement.
- Issue of open-ended spec. I propose that we limit to Recs that exist at time
of publication. We can update later.
- Also issue of when the spec becomes available. What happens when DOM 2 comes
out? You can't expect any implementations. We had this in ATAG 1.0; took the
approach of clarifying in the spec. You don't want conformance to the same spec
to change over time as much as possible.
IJ: We might want to add the word "available" to 6.2.
IJ: Same for 11.1 (WCAG). I think we need to limit to WCAG 1.0.
JG: Also want to be sure that DOM includes features that will benefit accessibility.
RS: DOM 2 gives you a standardized event model.
Resolved:
1) Change 11.1 to refer to WCAG 1.0 specifically.
Action Ian: For 6.2, propose some wording to address the "when available" issue.
Proposed:
1) Reduce the scope of 5.1 to say "write access only for that which you
can do through the UI." This would apply for form controls, style sheets.
In short, give the same write access to everyone.
HB: You need to be able to "undo" as well.
RS: DOM 2 includes some style abilities.
IJ: How does an AT get notified of content changes? (Checkpoint 5.4).
RS: Add an event listener. MS has reams of documents on this. Our group is doing work with this.
Action RS: Send some code to show how to listen to content changes.