Chair: Jon Gunderson
Date: Thursday, Feburary 17th
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
This is a special telecon of the User Agent working group. The user agent working group has invited additional assistive technology developers to this meeting to discuss the checkpoints in the current user agent guidelines related to assistive technology compatibility with user agents. One of the main issues for discussion is the use of the W3C Document Object Model for accessing information about the content of a WWW document.
Chair: Jon Gunderson (UIUC)
Scribe: Ian Jacobs (W3C)
Present:
Charles McCathieNevile (W3C)
Mickey
Quenzer (Productivity Works)
Denis Anson (College Misericordia)
Jim
Allan (Texas School for the Blind and Visually Impaired)
Gregory J. Rosmaita
(VICUG NYC)
Harvey Bingham (Yuri Rubinsky Foundation)
Kitch Barnicle
(Trace Center)
Jim Edwards (AI Squared)
Cathy Laws (IBM)
Kip Harris
(IBM)
Sheela Sethuraman (CAST)
Glen Gordon (Henter-Joyce)
Doug
Geoffrey (GW-Micro)
Hans Riesebos (ALVA Corporation)
Dick Brown
(Microsoft)
Rich Schwerdtfeger (IBM)
Philippe Le Hegaret (W3C)
Regrets:
Markku T. Hakkinen (Productivity
Works)
Daniel Simkovitz or another representative (Visionware Software,
Inc.)
Mark Novak (Trace Center)
Marja-Riitta Koivunen (W3C)
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0314.html
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.
JG: provides process background.
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.
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.
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.
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:
1.Example code
2.On-line resources
3.Access to experts
4.Other types of resources
5. FTF workshop
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.