Re: Raw minutes from UA teleconf 3 Feb 2000

see comments below at MN:

At 3:32 PM 2/3/00, Ian Jacobs wrote:
>Participants:
>
>Jon Gunderson
>Ian Jacobs
>Harvey Bingham
>David Poehlman
>Gregory Rosmaita
>Dick Brown
>Kitch Barnicle
>Denis Anson
>Mickey Quenzer
>Rich Schwerdtfeger
>
>Regrets:
>Marja Koivunen
>Charles McCathieNevile
>
>NEXT MEETING: 10 February 2000 @2pm ET
>Regrets: Ian, Marja
>
>Agenda [1]
>[1]
>http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0231.html
>
>1) Open Action Items
>
>   1.IJ: For 4.10 add the CSS2 property. And cross reference 4.7
>techniques
>
>   2.IJ: For 4.11 add the CSS2 property.
>
>   3.IJ: XWindows techniques for 5.3
>
>   4.IJ: DOM2 techniques for 5.3 (if any)
>
>   5.IJ: For 6.2 add a link to the TR page. Add links to conformance
>         sections in specs. Also to validation services.
>
>   6.IJ: Fix section numbering in techs doc in checkpoint 7.3
>
>   7.IJ: Ensure that checkpoints are in proper priority order.
>
>  Status of all Ian actions: Not done.
>
>
>   8.JG: for 5.3: Find out windows/mac accessibility guidelines.
>
>  Status: 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?
>
>  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.
>
>
>2) Telecon on 17th on the DOM.
>   JG: List of people contacted on the home page.
>
>3) CR Update and discussion
>
>   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: Send request for times to adminreq.
>
>4) FTF meeting update
>
>   JG: The ball's in Judy's court. Dates are those discussed for
>       April.
>
>5) Discussion of techniques for checkpoint 5.5 Ensure that programmatic
>     exchanges proceed in a timely manner.
>
>  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.

MN:  Please refer to the Tech DOC.,  COM is *not* limited to
out-of-process only.  The Browser Helper Object (BHO) is an
in process DLL, which uses COM to communicate and interact
with IE in a very fast manner.  It does not suffer any system
scheduling problems when run in this manner.



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

MN:  Without invertigating the methods used, I'm not sure you
can make any conclusions based on this.   For example, injecting
keyboard information at the device driver level using a virtual device
driver in Windows (Vxd) can be much slower than  injecting
keyboard information using the Win32 keyboard API.  It
also could just be poorly written code.



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

MN:   yes and yes


>
>  RS: I'd like to see "in-process" happen. It would take significant
>      changes to MSAA to make that happen.

MN:  I'm not following this statement at all.  Using a BHO, I have
access to all the information in IE's DOM.   Where does MSAA play
a role?


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

MN:  I think the issue of "in-process", "out-of-process", etc., is beyond
the scope of the UA group.  All the methods ought to be listed, as in the
Tech. DOC., and it is up to the AT developers to decide what works
best for their product/market.

MN:  I realize the UA group is trying to define "timely", and that is
why I suggested developing a reference prototype/platform about
two weeks ago.


>
>   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.
>
>
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel/Fax:                     +1 212 684-1814 or 212 532-4767
>Cell:                        +1 917 450-8783

Received on Thursday, 3 February 2000 16:15:56 UTC