- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 24 Feb 2000 09:07:14 -0500
- 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 UTC