W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2002

Raw minutes from 28 Mar 2002 UAWG teleconf

From: Ian B. Jacobs <ij@w3.org>
Date: Thu, 28 Mar 2002 17:05:16 -0500
Message-ID: <3CA3939C.80004@w3.org>
To: w3c-wai-ua@w3.org
[I thought I already sent these; my apologies if these
appear twice.]

UAWG teleconference, 28 Mar 2002

Agenda announcement:

Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe) Lee
Bateman (HP), Glenn Gordon (Freedom Scientific), David Poehlman,
Loretta Guarino (Adobe), Richard Potter (Adobe), Harvey Bingham,
Cathy Laws (IBM), Randy Marsden (Madenta), Tony Pitman (Madenta),
Jill Thomas (ION), Pat Brannan (ION), Roberto Gonzalez (Alva),
Jos Eckhart (AI Squared), Philippe Le Hegaret (W3C, DOM WG), Tim
Lacy (MS), Aaron Smith (GWMicro), Aaron Leventhal (Netscape),
Rich Schwerdtfeger (IBM)

Absent: Jim Allan, Eric Hansen

Previous meeting: 21 Feb 2002

Next meeting: 4 April

Reference document 12 September Candidate Recommendation:


1. DOM requirements for UAAG 1.0 (AT developers invited)

/* JG gives background about UAAG 1.0 Candidate Rec and DOM
requirements (Guideline 6) */

Refer to comments from Ian:

JG: We would need to clarify what information (minimally) would
be required for any API.

RM: Are you referring to any old "document object model" or
a specific W3C DOM?

JG: W3C Dom 2 Core:

DP: Would be helpful if we included pointer to the minutes
for information to be included in future DOM.

PLH: We provide two official bindings of the API. Those
bindings are in ECMAScript and Java. If you are implementing
the DOM in C/C++, we don't guarantee the interoperability. Some
people are remapping the API to new names, for example.

AL: What this means in practice, is that if you are a screen
reader developer, and write a solution for NN, it might not work
for Opera. However you get to the information will be different
for each solution. Unless you do it in javascript, for example.

PLH: Outside of java and ecmascript, we don't guarantee

AL: So, between NN and IE, there are two different ways to refer
to a DOM node.

PLH: Two requirements:
  1) Interoperability: Can't guarantee for all bindings today.
  2) Functionalities: Developers *are* trying to reproduce these
     functionalities in other contexts.

GG: I originally thought that the DOM would provide a common
interface, and that with few changes, you could embrace one
person's DOM as easily as the next. If that view doesn't hold,
my positive view drops a little. We are not using the DOM
currently, but I do like the structured approach to content
access. I have concerns when developers make other choices
that may limit information. I like the richness of the DOM. I
would like more consistency across platforms. But if everyone's
presentation of the DOM is going to be different, it's not clear
that's helpful.

AL: It will be 90% similar, let's say. The information will come
across the same way (e.g., if you ask for the tree, methods,
etc.). The methods and objects will be the same, but the C++ code
will look different.

GG: If there's a mandated DOM, why no mandated external

RS: I've been asking for a standard interface cross-platform.

PLH: We don't provide a normative C++ binding since there was no

RS: It would be nice to have the standard bindings, e.g., for

PLH: Gnome people are implementing the DOM, but are providing
their own binding. They were disappointed by not having a
w3c-sanctioned C++ binding. But they are implementing.
Refer to http://www.levien.com/gnome/gdome.html

CL: Right now, HPR is primarily using the DOM to implement its
interface. But using the COM interface to the IE DOM. We would
like to go cross-platform (in C++). We can't do everything
through the DOM. For instance, can't find out position/attributes
of a given character. The DOM can't do everything we want to do,
but it does to a majority of what we do.

RM: We're not using the DOM. A couple of comments:

  a) A lot of what I've heard here about the DOM I've also
    heard about MSAA ("Meets most but not all needs.").
    Perhaps the standard DOM gets you 80% of what you need,
    and vendors should document how to provide the other 20%.
    I could, as an AT vendor, implement the other 20% for
    extra information.

  b) We come from physical disability environment. Generally
    speaking, it's harder to solve problems related to blindess
    than physical disabilities. Right now, the UAAG 1.0 assumes
    the presence of a keyboard. That cuts out all of our users,
    who can't use a keyboard.

    IJ: We have a requirement for implementation of standard
    keyboard API. Is that enough?

    RM: For our users, pointer is more relevant.

    JG: Sounds like your alluding to a functional API. We don't
    have a means to do that today. Instead, we require full
    keyboard support of all functionality, and support for the
    standard keyboard API. That's the best proposal we have

    RM: We should take the blame as well as we were not around
    the table for this discussion.

    DP: Two things:

     a) We've gone in this direction because we are assuming
     that pointing devices are already supported.

     b) In support of Randy, Brian Campbell has been doing
     work in this area and has worked with us in the past.

    JG: Denis Anson has also been a proponent of physical

    LB: How about voice-activated systems?

    IJ: We allow conformance for voice, but don't require it.
    We expect that combination of minimal keyboard bindings,
    plus keyboard API, plus checkpoint 1.1 that most developers
    will be able to plug into functionalities.

PB: We use a standard DOM implementation and everything works
quite well. On the C++ side, I'd echo the comments that we tried
and wound up going another route on IE-based products since the
DOM implementation is not consistent enough. If I can't get a
well-formed DOM, it does me little good. We are using the MS DOM
model. We moved into using their elements; we are a reader and
want access to the content. Our number one issue is that there's
a lot of invalid content out there.

DP: Do you consider yourself a primary user agent or more of an
assistive technology?

JT: WebEyes works with IE.

DP: I was talking about EMonocle.

JT: EMonocle reads an OAB file. In that respect, I wouldn't put
in the same class as a browser because it is reading a
well-formed document.

DP: Does this also allow ATs to interact with EMonocle? If it
does, then other developers might want to take advantage of some
of this capability.

JT: Part of our strategy is to allow other ATs to work with
EMonocle as well as with WebEyes.

IJ: What hooks do you provide?

PB: We don't use the (IE) DOM. For the body of content we're
trying to use, it's impossible to generate consistent DOM objects.
Both WebEyes and EMonocle are AT-focused. We use MSAA on the
Windows platform.

AL: What do you mean by inconsistency?

PB: We re-render in more accessible format for people with
limited vision to read. The browser needs to provide us with
a fully functional DOM object. My experience with real-world
content is that there are bugs in the DOM objects that are
produced; this renders them almost impossible to use.

JT: Some effects:
  - Duplication of text
  - Missing text

PB: I think a normative C++ binding would be very valuable.  You
need a consistent result from one user agent to another. We have
a common API, but not common implementations.

RS: I'd like to see user agents implementing the core DOM
and events module. If they are supporting that level of
functionality, you can get a lot done. You can't prevent
a user agent from wanting to add extra features.

CL: We have had to access attributes as well as elements
to get reasonable content. Bad content has been a problem
for us.

TL: When IE reads markup, it goes into "markup services",
just a stream to hold the stuff. The parser reads that
and builds the DOM. I think it also builds the MSAA
tree at the same time. We do some repair work when
we read the DOM and produce the graphical display (mostly
to address poorly formed HTML). The DOM should reflect
the input accurately. The MSAA tree will be a subset of the
DOM. Walking the MSAA tree is easier than walking the
DOM tree. So, the MSAA tree is not the same as the DOM
tree, and is supposed to be easier to use.

TL: MSAA information is not necessarily more in line with what's
rendered. As of IE 6, you can do "round-tripping" to query MSAA
nodes and get its corresponding DOM node.  And vice versa (DOM to
MSAA for equivalent MSAA node if it exists).

DP: There's an accessibility link in the MSDN Web site.

RG: I know we've tried implementing a combination of techniques
and, to my knowledge, we mostly went with MSAA at this point,
only because of inconsistencies (and possibly lack of

JG: At one point, Hans Riesebos (Alva) was advocating the

RG: In theory, it seemed like the DOM was something we
absolutely supported. But in practice, when implementing,
it wasn't usable.

AL: Do people think that the ability to query back and
forth from DOM and MSAA nodes is useful?

RG: Yes, I think it's useful.

CL: Yes, I think it would be useful from our perspective.
E.g., for information about characters, we'd like to use
the DOM node as a reference and jump to the equivalent
MSAA node.

PB: I think it would definitely be useful.

AL: We have something similar in Netscape. But I think
that the DOM node we give does not allow full write access.
We write an interface called iSimpleDOMNode. It doesn't allow
write access; you can read attributes, tags and style

JE: We don't use the W3C DOM and we don't use MSAA. We use the
COM interface to the DHTML. The problems we have is a little
bit like IBM's: we need information about rendered information
(where is something on the screen). We'd also like to have
structure information about the content (how the document
is organized). We want more information about how the
author meant to organize the page.

IJ: What could UAAG 1.0 do better to promote interoperability
and accessibility? Is the DOM requirement the right one?

GG: I have more questions for answers:
  - We all have slightly different needs and infrastructures.
    This makes a DOM or any other implementation easier or
    more difficult.
  - Given the state of the world, I'd be tempted to say:
    * Use some published API.
    * The closer to a standard API you are, the more likely
      AT vendors will adopt.
    * Look at other Access APIs if you don't want to use the
    * Footnote: The further down you go down the cascade, the
      harder time you will have getting interoperability, and
      the higher the risk of failure.

/* LB leaves */

RS: I'd like to see the DOM required (e.g., you need access
to namespaces, schemas, ...). If you don't require a
cross-platform standard, you will have delays in getting
access to this information into platform-specific APIs.

PLH: The DOM API will not give you access to everything you want
(notably to the rendering structure). As of today, the DOM is not
enough. On the other hand, regarding access to content, one of
the reasons we developed the DOM API was that what was available
on the Web was insufficient and not well-designed. IE 3 and NN 3
object models did not match the HTML specifications at all.
If you say that people are free to implement their own API,
you will end up with broken APIs.

LG: We are looking into exporting content through something
at least based on the DOM.

RP: It would be interesting to get a C++ binding; that would
be a big win. The trouble with the DOM is also Web-centric.

LG: For all the reasons we're having this discussion, even
with PDF, we'd like to be as consistent as possible even
with PDF.

RP: Platform-independence is a big win.

RS: We are talking to a large number of AT vendors dealing
with HTML content on Windows.

JT: EMonocle runs on three platforms. Using the DOM helps
us run on all of them.

LG: If we have something similar to, but not identical to,
the W3C Core DOM, will that still help AT developers?

RS: What about the SVG DOM (since closer to PDF)?

RP: I don't think AT developers would use the SVG-specific
part of the DOM. We'd be more interested, but need a
C++ binding...

Action RS: Talk to Arnaud Le Hors about this issue, for
re-raising in the DOM WG.

PB: I think the current UAAG 1.0 DOM requirement is fine.
Our biggest problem is the content base. This is not news
to anyone. It's hard to develop a valid DOM for a whole
lot of Web content. I wish user agents weren't quite so
accepting. XHTML content is great, for example. But you want
to serve the lowest common denominator; today can't be done
with the DOM due to the nature of content out there.

AL: If you were to come up with the top things that people
would use the DOM for, it would be about 10 things (nodes
attributes, text values). The ability to match up DOM/MSAA
seems more valuable matched with getting 10 things you might

Action everyone: Send to the WG the top 5 things you need
through an API. Deadline: One week from now.

JG: We will collect that and then get comments on a compilation
of what people sent in.

2. Implementation Report Update

JG: I added IE 6 evaluation.

Action IJ and JT: Coordinate on EMonocle evaluation.

Completed Action Items
TL and JG: Review initial implementation report for IE 6.0 and comment
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0191

DP: Jaws 4.01 and IE 6.0 evaluation
Sent yesterday.

Open Action Items

RS: Write up paragraph about the importance of thread-safe
     access for in-process ATs.

Status - not done yet.

HB: Contact ION Systems for a review of their EMonocle
     with UAAG guidelines

Jill: I have a time and resource issue. We are interested,
but haven't gotten to it.

IJ: I will help with it.

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Thursday, 28 March 2002 17:05:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:32 UTC