W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Raw minutes from 23 February WAI UA

From: Ian Jacobs <ij@w3.org>
Date: Thu, 24 Feb 2000 09:07:14 -0500
Message-ID: <38B53B12.41A848BA@w3.org>
To: w3c-wai-ua@w3.org
WAI UA Teleconf
23 Feb 2000

Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita
David Poehlman
Mickey Quenzer
Harvey Bingham
Denis Anson 
Rich Schwertdfeger
Hans Riesebos
Mark Novak
Glen Gordon
Dick Brown
Philippe Le Hegaret
Charles McCathieNevile

Regrets:
Daniel Dardailler
Kitch Barnicle

Next meeting: TOMORROW at 2:30 ET.

Agenda [1]
[1] ??

1) Review of Action items:

   IJ Action items: All done.
   JG: 
     -For 5.3, find Mac access guidelines (not done)
     -Contact IJ about stepping through AV (not done)
   DA: Write techniques for 2.2 (done, not in document yet).
   DB: Ask IE team about publishing IE reviews.     
   GR: Send techniques about control of focus. (cancelled)
   JA: Techniques for 3.3 (no news)
   MK: No news.
   MR: No news.
   MQ: Cancelled.
   RS/IJ: Timing issues to PF (pending).

2) Announcements:
   
   - Telecoms: 24 Feb, 1, 2 March.
   - CSUN WAI meetings.
   - UA ftf 10-11 April (no new information from Judy)
   - JG and IJ are putting together a summary of the CR review.
     Will submit to WG for review.
   - Hope to go to PR on 8 March (in time for ftf).
   - IJ will talk to an MS rep working on IE/Mac about UA Guidelines.

3) Candidate Rec issues related to the DOM (190, 201 and 203)

     - Read-only access to the DOM?
     - Timely exchange of information
     - Programmatic access to non-HTML/XML content

   Refer to JG's proposal of 22 February (URI?)

   <BLOCKQUOTE>
   5.a Make available content information available to other
technologies
   through an API [Priority 1]
   </BLOCKQUOTE>

   IJ: Please refer to my proposal that reuses wording of existing 5.3

   DA: Programmatic access to rendered content.

   CMN: A UA might ignore content, but pass it off. 
 
   JG: A graphical style sheet might ignore an auditory style sheet,
       but an AT might want it.

   Resolved: Add this checkpoint for content.

   <BLOCKQUOTE>
   5.b Provide programmatic access to XML amd HTML content by conforming
to
   W3C Document Object Model (DOM) level 2 Core and HTML module
specifications
   and exporting interfaces defined by those specifications. [Priority
1]  

   Note: Important special case of Checkpoint 5.a and that the timing
   efficiency of exchanging information through the exported interface
is very
   important.
   </BLOCKQUOTE>

   PLH: DOM Level 2 core is same as DOM Level 1, plus namespaces. DOM
        Level 2 HTML is same as DOM Level 1 HTML.

   GG: I think a perfect example of this is MSAA available in IE 4.01.
       You could get at the data if you had a whole lot of time. I
       think that timeliness should be Priority 1.

   RS: I think we want the same performance as for a scripting
       language.

   CMN: You need to know about events in a timely manner, and perhaps
       be able to react (and stop) the results of events.

   IJ: I have problems with a requirement that something be "fast".
       That may vary according to processor, network, operating
       system, interface, user ability, ...
 
   RS: Since we're isolating the DOM as part of the UA, can we say
   that the AT should be able to access the DOM at the same performance
   level as the UA itself. 

   DA: You want "equivalence" of access.

   HR: I don't think we need equivalent, just sufficient.

   DA: I think that a lot of people with disabilities would argue that
   anything less than equivalence doesn't suffice.

   PLH: When you rely on your own structure, you can access faster
   than what you can do through the DOM. So I don't think that you can
   guarantee "equivalent" access. It may be implemented as a proxy.

   IJ: What are the functional disadvantages by not having fast
   access?

   GG: You lose responsiveness, but that's not functional.

   DA: Consider two people doing research - a person who is
   able-bodied might be twice as productive as someone who is using an 
   AT.

   CMN: If the AT doesn't have enough access, the page will change
   before the user has read it. For example, caused by timers on
   scripts.

   IJ: We have a requirement to allow users to turn off dynamic
   changes.

   DP: But sometimes you need to have content changes to remain
   oriented, and if the AT doesn't keep up, you've lost your
   orientation.

   PLH: Maybe you're looking for atomic interactions. In a SMIL
   document, you want to change the "begin" attribute but not the
   "end" attribute. The implementation may change the end attribute.
   There are two operations and you want only one. 
 
   PLH: An API offered by the UA will never be as fast as the UA's
   internal calls.

   GG: Yes, but this is must better than cross-process calls.
 
   IJ: Something like "The UA must allow access as though the AT were
   running in the same process."

   CMN: The AT has to be able to control the processing of any changes.

   IJ: This is better to me since it doesn't refer to "speed".

   JG: Two separate timing issues have come up:
      - It's slow to get at content.
      - I need to be able to keep up with changes.

   GG: I think these are intimately related. 

   RS: The DOM (2) allows you to have filtering. If we stay with
something
       about equivalence performance level, then filtering of events
       would do the same thing.

   IJ: I really hesitate to go into the world of handshaking and
   protocols.

   DA: The bottom line: can the user of an AT be as productive?

   IJ: Speed is not part of our priority definition. Slow access still 
       means that it's not Priority 1.

   MN: I think that this is a high priority issue. I'm mulling over
   RS's expression of the problem. An in-process DLL will get content
   faster than a script. I think we should use technologies that are
   already available to us. 

   JG: A reference implementation may be useful to people (to show
   what's reasonable performance).

   MN: Other applications are addressing this problem as well. It just 
   needs to be implemented. Developers keep in the front of their
   minds to do things quickly.

   CMN: There's an orthogonal break between how it's being implemented 
   and what we specify. If it's implemented, that's great, but how do 
   we specify the requirement in the first place (so that it may be
   verified).

   MN: The idea being as quick as scripting we can relate to and it's
   do-able. 

   HR: I think that timing is important. When I'm using the DOM, the
   most important thing is to be in sync with the user agent. The key
   word is "synchronized" with events generated by the user agent.

   RS: You could put something in sync and slow the whole application
   down.  

   HR: Having the events in sync is only part of the solution. This is 
   the part we can identify more clearly. Performance is the real
   issue.

   IJ: What about "The UA has to provide programmatic access to
   content in a way that allows comparable performance to AT users."

   CMN: I don't think that's adequate.

   HR: In-process communication is not really developed for the Mac.

   RS: What if we say "For multitasking environments, the AT needs to
   run in the same process space as the UA for access to the DOM."

   DP: The AT needs to do some processing once it's hooked in to the UA. 

   DA: In David and Charles' proposal, the AT slows down the UA. I
   think that we should be considering how to go as fast, not to slow
down.
  
   DP: The hook needs to be early in the processing.

   IJ: Scope of the problem is dynamic changes to document.

   RS: Not always: and AT may only deal with part of the document.

   GG: Sometimes, you need to get a lot of calls to get summary
       information.

   MN: Static pages may be so large, there's an issue of getting
       information, period.

   CMN: I think that there are two issues: (a) dynamically changing
pages
       (b) how to do you deal with a big fat monstrous document. The
       Pri 1 content is only when you can't get at the information at
       all.

   IJ: Isn't rendering orders of magnitudes slower than exchange? Is
   there really an issue for static documents?

   GG: If you want a list of all the links, you may have to wait 20
       seconds for all the content to download.

   CMN: But you still have that today for downloads (e.g., the long W3C
   list of 400 Members).

   CMN: I think we need a requirement for at least dynamic content.

   CMN: I'm not saying that static is not important. The piece that's
   critical is when content changes before you get at it. When the
   content is steady, you need to get at it in a reasonable amount of
time.   
   The best techniques may satisfy both requirements. But we should
distinguish
   the cases.

   DA: I would agree with CMN that dynamic is P1 and static is P2.

   IJ: How about a requirement that the exchange of information take
       place on the same time scale as event changes.

   JG: I still propose that we delete 5.5 and make the requirement in
       a note after each programmatic exchange checkpoint.

   GG: I think that the dynamic case is just as important as the 
       static case (for different reasons).

   RS: Treating them separately confuses me.

   CMN: We want the AT user to be able to have the lock so that the
        user can stop the chain of events if necessary.

   DB: Is there any place else where "timely manner" is defined?

   Action IJ: Propose a checkpoint by Friday.

-- 
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, 24 February 2000 09:07:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT