W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for Feburary 17th, 2000


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


Agenda

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.

Announcements

  1. FTF meeting information
  2. Additional telecons scheduled for 23 February and 1 March

Discussion

  1. Update on current state of the UA guidelines and W3C process overview
  2. Using DOM to access WWW content
    1. Overview of the DOM and its capabilities
    2. Interfaces to the DOM
    3. Read only versus read/write access
    4. Checkpoint 5.5 Ensure that programmatic exchanges proceed in a timely manner. [Priority 2]
    5. Event model implementation for simulating events
    6. UIML based user interface design
      http://www.uiml.org/
  3. Resources needed to help AT developers use the DOM in their products
    1. Example code
    2. On-line resources
    3. Face to face workshop
    4. Access to experts
    5. Other types of resources
  4. Other Checkpoints in Guideline 5 (28 January CR Draft)
    1. Checkpoint 5.2 Provide programmatic read and write access to user agent user interface controls using standard APIs (e.g., platform-independent APIs such as the W3C DOM, standard APIs for the operating system, and conventions for programming languages, plug-ins, virtual machine environments, etc.) [Priority 1]
    2. Checkpoint 5.3 Implement selection, content focus, and user interface focus mechanisms. [Priority 1]
    3. Checkpoint 5.4 Provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus). [Priority 1]
    4. Checkpoint 5.6 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation. [Priority 2]

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)


Action Items

  1. IJ: For 4.10 add the CSS2 property. And cross reference 4.7 techniques
  2. IJ: For 4.11 add the CSS2 property.
  3. IJ: XWindows techniques for 5.3
  4. IJ: DOM2 techniques for 5.3 (if any)
  5. IJ: For 6.2 add a link to the TR page. Add links to conformance sections in specs. Also to validation services.
  6. IJ: Fix section numbering in techs doc in checkpoint 7.3
  7. IJ: Ensure that checkpoints are in proper priority order.
  8. IJ: For 6.2, propose some wording to address the "when available" issue.
  9. JG: for 5.3: Find out windows/mac accessibility guidelines.
  10. JG: Check with Ian about adding reference in 4.5 to 4.6 in regard to stepping through animation/video/audio.
  11. DA: Rewrite technique for 2.2 (see minutes)
  12. DB: Ask IE Team about publication of review of IE 5 and Pri 1 checkpoints.
    Status: notes have been lost and are being reconstructed
  13. GR: Send to the list techniques for how to use and control focus to not have new windows cause problems for usability. In particular, how this will work with ATs.
  14. JA: Rewrite techniques for 3.3 (see minutes)
  15. MK: For 4.8 check if any media players do this?
  16. MK: Find out techniques for sending text search requests to servers of streamed text.
  17. MR: Review techniques for topic 3.1 (Multi-media)
  18. MR: Review techniques for Guideline 4 (Multi-media)
  19. MR: Run a multimedia player through the guidelines for January.
  20. MQ: Ask Mark Hakkinen about telephone browsers and the guidelines.
  21. RS: Take these issues to WAI PF. Get input from MSAA developers as well. Craft email to PF WG with Ian

Completed Action Items

  1. JG: invite PF Al, Daniel, CMN and Mark Novak to next meeting Feb 23

New Action Items

  1. PLH: Send URI to this work to the UA WG mailing list

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.