MINUTES(edited): W3C WAI User Agent 23 February 2000

  Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

RSVP Present:
Dick Brown
Harvey Bingham
Denis Anson
Rich Schwerdtfeger
Charles McCathieNevile
Mark Novak
Philippe Le Hegaret 
David Poehlman 
Mickey Quenzer 
Gregory J. Rosmaita
David Gordon
Hans Riesebos

Regrets: 
Daniel Dardailler 
Kitch Barnicle 

Action Items

Open Action Items

   1.JG: for 5.3: Find out windows/mac accessibility guidelines. 

   2.JG: Check with Ian about adding reference in 4.5 to 4.6 in regard to
stepping through animation/video/audio. 

   3.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints. 
     Status: notes have been lost and are being reconstructed 

   4.JA: Rewrite techniques for 3.3 (see minutes) 

   5.MK: For 4.8 check if any media players do this? 

   6.MK: Find out techniques for sending text search requests to servers of
streamed text. 

   7.MR: Review techniques for topic 3.1 (Multi-media) 

   8.MR: Review techniques for Guideline 4 (Multi-media) 

   9.MR: Run a multimedia player through the guidelines for January. 

  10.RS: Take these issues to WAI PF. Get input from MSAA developers as
well. Craft email to PF WG with Ian 

New Action Items 

   1.IJ: Propose checkpoint to address event notification timing issue and
possibly timely exhange issue 

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

   8.IJ: For 6.2, propose some wording to address the "when available" issue. 

   9.DA: Rewrite technique for 2.2 (see minutes) 
     http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0298.html 

  10.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: Dropped, since information already in techniques document 

  11.MQ: Ask Mark Hakkinen about telephone browsers and the guidelines
     Dropped: Telephone browsers will not be directly address in these
guidelines 

  12.PLH: Send URI to this work to the UA WG mailing list
     http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0353.html 



Minutes

Next meeting: TOMORROW at 2:00 ET.

Agenda [1]

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0355.html 

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 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0359.html 

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

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. 

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. 

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. 

Copyright  ©  2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules apply. Your
interactions with this site are in
accordance with our public and Member privacy statements. 


Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua

Received on Thursday, 24 February 2000 09:34:47 UTC