MINUTES( edited ): W3C WAI User Agent Telecon 17 February

Attendance

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)

Minutes

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



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, 17 February 2000 17:20:52 UTC