Chair: Jon Gunderson
Date: Wednesday, Feburary 23rd
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
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
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0355.html
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).
- 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.
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.