- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 17 Feb 2000 15:37:37 -0500
- To: w3c-wai-ua@w3.org
WAI UA Teleconf
Special DOM Edition
17 Feb 2000
Jon Gunderson (Chair)
Ian Jacobs (Scribe, W3C)
Hans Riesebos (ALva Corporation)
Cathy Laws/Kip Harris (IBM)
Glen Gordon (Henter-Joyce)
Kitch Barnicle (Trace)
Philippe Le Hegaret (W3C)
Harvey Bingham
Jim Edwards (AI-Squared)
Mickey Quenzer (Productivity Works)
Gregory Rosmaita (VICUG NY)
Doug Geoffrey (GW-Micro)
Jim Allan (TSB)
Denis Anson (Coll. of Miseracordia)
Dick Brown (MS)
Rich Schwertdfeger (IBM)
Sheela Sethuraman (CAST)
Charles McCathieNevile (after 1:10).
Regrets:
Marja Koivunen
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0314.html
1) Announcements
1. FTF meeting information
JB: We need to finalize the meeting in the next few days. Also,
people need to reconfirm their availability for the dates in
question: 10-11 April.
JG: We need at least four teleconfs to settle outstanding issues.
JG and IJ will follow up with Judy.
2. Additional telecons scheduled for 23 February and 1 March (2pm ET)
2) Discussion
1.Update on current state of the UA guidelines and
W3C process overview.
JG provides process background.
2.Using DOM to access WWW content
JG: At ftf in December, we decided to rely on DOM for
access to content.
http://www.w3.org/WAI/UA/1999/12/ftf-19991209
JG: Why the DOM?
- Standard access to structure.
- Don't recreate relationships based on graphical rendering.
JG: Useful to WG to know some of the reasons why some
organizations are already using a DOM or the W3C DOM.
CL: We're using the IE DOM. One main reason is that in HP 5,
we interpreted HTML, but couldn't handle Java. We're
waiting for Mozilla.
RS: One reason we're interested in the DOM is to be able
to monitor changes to documents.
KH (IBM): We are developing on top of IE as our first target. We
would then build on whatever IE starts. As a developer working on the
project, coming up to speed involves how the IE DOM maps to the W3C
DOM. We haven't done much with events yet, but will probably have to.
Imagine a scenario where a low-vision user and a sighted user are
collaborating. We need information about mouse events in our rendering
agent. E.g., changes to focus. Also, RS and I were discussing
yesterday about notification to our browser about changes to the DOM.
HB: How are changes to the DOM propagated to other user
agents?
JG: Sychronization has been a topic that the WG considers
needs to be addressed (in a timely fashion).
KH: I think it's important to have notification that some
piece of the DOM has changed.
PLH: What DOM are we talking about?
JG: Most of the developers here are probably familiar with the
IE DOM.
PLH: The IE DOM includes all of W3C DOM Level 1 and some of DOM
level 2.
JG: I proposed last week that we limit read access to DOM
Level 1. And some other parts of DOM Level 1 for writing.
This is on the agenda for next week's meeting.
GG: It's hard to get useful events from IE's implementation
of the DOM. You don't know which elements may be changed
through external scripts. We track other events (document
load, window open, etc.)
RS: One problem is that IE's DOM is inbetween DOM 1 and DOM 2.
Glen's issue "Where do I attach my event handlers?" is one
we're dealing with in the DOM WG.
SS: CAST's E-reader is not really a screen-reader since it
doesn't target blind users. More for users with learning
disabilities. The graphical rendering is critical. Also
text-to-speech. We host the IE component in our shell for the browser
functionality. Our developers are currently working with Form
elements. Those are the events where we would want event
notification. I haven't run into any serious problems yet with the IE
DOM. At this time, information about loading, or window spawning, is
available to us. Some of our limitations are due to the limitations of
the IE component.
DG: With Windowize, we get most information through MSAA. But
that doesn't give us everything that we need.
JE: We don't have any experience with the DOM. We rely on MSAA
and an offscreen model. DOM looks like it has a lot of potential. I'd
be interested in knowing what applications support DOM.
PLH: IE5 supports DOM level 1 and part of DOM level 2. Netscape
is not DOM Level 1, but Mozilla will be completely DOM Level 1
enabled. Operasoft intends to support DOM 1/2.
JG: I don't know about multimedia players.
PLH: IE 5 plans to support the SMIL DOM. Also, RealNetworks
plans to support the SMIL DOM.
JG: Is DOM compelling for the Mac environment where there is
isn't MSAA?
HR: Yes. DOM will be very useful, also for XML applications.
/* 2.Interfaces to the DOM */
JG: Note that IE uses the COM model to allow assistive
technologies to access the DOM.
PLH: But COM is a DOM-binding. The DOM spec provides
three bindings: ECMA-script, IDL (Corba), Java.
RS: For DOM 3, we want to require that binding names map
specifically to names in the DOM. This will save effort for assistive
technologies. E.g., the IE DOM API name doesn't match the W3C DOM
name.
/* 3.Read only versus read/write access */
JG: One developer suggested that read access was the primary
requirement for ATs, and write access was only important for things
like form controls, or other elements that can be modified through the
user interface. Would this satisfy AT demands?
SS: I think that as a first pass, read access is more
important.
IJ: One way to formulate the propoposal was that you have to
be able to do through the programmatic interface what you can do
through the UI.
RS: You may want to insert bookmarks on the fly. You may also
want to impose style changes.
KH: We need to be able to manipulate the input elements. We
might also want to highlight elements dynamically (e.g., bouncing ball
effect). We might have to manipulate some style properties.
PLH: There is a range interface in DOM Level 2.
RS: There isn't a selection model in DOM Level 2.
DA: Are bookmarks persistent?
RS: Current examples are not.
DG: At some point I'd like to allow the user to fill out
forms.
MQ: Jaws for Windows modifies the view sent to the user. They
put table row and column information in the document tree.
/* 4.Checkpoint 5.5 Ensure that programmatic exchanges proceed in a
timely manner. [Priority 2] */
RS: We did some initial testing about accessing the DOM
out-of-process (e.g., in Windows, through the COM module). It was 12
times faster in process. Currently, in-process not possible unless you
embed the browser in your application. We have been struggling with
the issue of how to define "timely".
DG: The DOM in IE may be responsive, but the COM has a
tremendous amount of overhead.
RS: That's right. We'd like to have a technique for getting at
the DOM in process. How to we clarify what "timely" means at the
checkpoint level? A scenario where it becomes a problem: sizeable
document, listening for changes. In this case, the performance
degrades exponentially. Glen Gordon complained that the performance
hit caused lots of problems. So the question is: how do you specify
the "timely" requirement?
DB: We've been trying to get Rob Sinclair and Rob Rylea
involved. I can't offer much at this point.
RS: One suggestion: "Provide access to elements in-process."
IJ: That sounds like a huge implementation requirement.
RS: I don't think so. All systems have the notion of a
registry. It would be possible for user agents to launch assistive
technologies and communicate with them in-process. For AT vendors, it
means being able to handle caching operations and being able to talk
with the "mother" user agent. Take the Java example: a Java process
can load an assitive technology. Very very fast.
HR: Often, in timing, there is information in events. "Timely"
means that the information in the events must be available on
different timing scales.
IJ: So you have to be able to preserve information across
different scales.
SS: Does this mean that timing issues are negligible when the
AT is in-process?
RS: Accesses in-process were on the order of tenths of
nanoseconds. COM is smart, so in-process, doesn't do mappings that
take time.
DG: I think that performance is critical to being able to use
the DOM.
SS: Does timing mean more than no loss of information? Does it
include an upper limit.
IJ: I would object to timing requirements. Also, it sounds good
to say "timely means that information conveyed by events is available
to assistive technologies" but, how to know how to verify this?
HR: A second timing issue - responsiveness of the system to user
interaction. Ten seconds is too long. Then this becomes a performance
issue. But I don't have a way to address this.
PLH: I don't think that it makes sense to impose timing
requirements on user agents.
DA: So talk in absolute time, but in terms of
overhead. E.g. "1.5 times as fast".
JG: I don't think we can do this.
RS: What we are trying to do is create an "engine extension". ..
JG: I hear developers saying this is an important issue.
IJ: I really don't see how we can talk about performance
requirements, even though I realize that the user's experience is
important. What is the functional requirement?
JG: I want to continue the timing issue on the list.
---
JG: What resources would be useful for people? The survey showed these
requests:
3.Resources needed to help AT developers use the DOM in their
products
1.Example code
2.On-line resources
4.Access to experts
5.Other types of resources
JG: People did not seem to consider a workshop crucial.
DG: I also wanted well-written documentation. When experts aren't
available.
SS: I think that demo code is critical. Also interaction with
experts is critical. Also other developers with experience.
I don't know how you intend to implement available experts. I'd
suggest making this specific.
JG: I can't guarantee these resources. I want to take information back
to the WAI on what developers want.
KH: I think that the above order is a good one.
HR: A reference implementation of the DOM would be helpful. Without a
large mother application.
PLH: I know there's a generic DOM module developed by IBM, called, I
think "Weblet". The goal is to build the Java DOM for the browser. It
runs with IE, and the developer is working on the Netscape version.
Action PLH: Send URI to this work to the UA WG mailing list.
--
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, 17 February 2000 15:38:09 UTC