- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 28 Mar 2002 17:05:16 -0500
- 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:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0114
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
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0100
Next meeting: 4 April
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
==========
Discussion
==========
1. DOM requirements for UAAG 1.0 (AT developers invited)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0085
/* JG gives background about UAAG 1.0 Candidate Rec and DOM
requirements (Guideline 6) */
Refer to comments from Ian:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0085
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:
http://www.w3.org/TR/DOM-Level-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
interoperability.
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
interface?
RS: I've been asking for a standard interface cross-platform.
PLH: We don't provide a normative C++ binding since there was no
interest.
RS: It would be nice to have the standard bindings, e.g., for
Gnome.
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
today.
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
access.
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
documentation).
JG: At one point, Hans Riesebos (Alva) was advocating the
DOM.
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
information.
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
DOM.
* 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
need.
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
http://www.w3.org/WAI/UA/implementation/report-cr2
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.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0100
Status - not done yet.
HB: Contact ION Systems for a review of their EMonocle
with UAAG guidelines
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0082
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