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

Raw minutes from 16 May 2002 UAWG teleconference (API requirements, DOM)

From: Ian B. Jacobs <ij@w3.org>
Date: Thu, 16 May 2002 15:35:01 -0400
Message-ID: <3CE409E5.9090301@w3.org>
To: w3c-wai-ua@w3.org
UAWG teleconference, 16 May 2002

Agenda announcement:

Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe), David
Poehlman, Eric Hansen, Loretta Guarino Reid (Adobe), Cathy Laws 
(IBM), Jill Thomas (Ion Systems), Patrick Brannan (Ion Systems), 
Bill Haneman (Sun/Gnome), Philippe Le Hegaret (W3C), Rich 
Schwerdtfeger (IBM), Tim Lacy (Microsoft), Al Gilman, Jost Eckhardt 
(AI Squared)

Regrets: Jim Allan, Harvey Bingham, Glenn Gordon, Roberto Gonzales.

Previous meeting: 9 May 2002

Next meeting: 23 May, 2pm ET.
   Regrets: Harvey (next 2 weeks)

Reference document 12 September Candidate Recommendation:


1. Issue 529: 6.1, 6.2: Is DOM required at P1, or some API?

See proposed resolution of issue 529:

(A few people have read the proposal before attending the call.)

RS: PFWG did ask for rendering information about 1.5 years ago; no
time to put into DOM.

PLH: Views and Formatting is not being developed by DOM WG. No
companies (other than Netscape, perhaps) are willing to work on this
right now.

AG: This is not a new idea. We have to take PLH's advice as the 
state of the world: you can't project any sort of delivery date out 
of DOM WG.

PLH: As of today, we've received no input to continue this work.

(IJ summarizes proposal)

AG: A quick look at the proposal:
  a) Suppressing DOM where not normative bindings. Seems like
     it's on thin ice to say "use something like the DOM where
     non-normative bindings". Delete that.
  b) Adding access to rendering structure.

RS: What I think is needed - UA developer needs to document
bindings. UA developers needs to show how API maps to W3C DOM.

IJ: We would require public documentation of API.

RS: We understand that implementations of DOM may vary, so UA
must document their implementation on W3C Web site.

PLH: We do have a page to reference non-normative bindings on the 
W3C Web site. In the case of C++, we only had one submission (I 
think from Oracle).

JG: Can we request that the DOM WG do this?

RS: We can request that info be documented at UA Web site if not DOM
WG Web site.

BH: I think we have a deeper issue here than the question of
bindings. I would want to avoid the unintended effect - if the DOM 
is stated as the API of preference for access to content, there is a
possibility of a negative side-effect. It could encourage UA
developers to provide access to content instead of view-based 
access. Different user agents will tend to interpret content and 
style sheets differently. Implementations are imperfect; legacy has 
an impact. Don't offload chore of calculating view from original 
content. Screen readers, if couldn't have direct view access, would 
have to extract information from the DOM. If we make the DOM the 
preferred method, we might discourage work on view API.

BH: Is the IDL for DOM normative?

PLH: We use the Corba IDL in the DOM Specifications. It is 
completely useless to try to use the IDL provided by the DOM spec in 
a Corba environment. We are only using it as an abstract language. 
It's not meant to be implemented client-side. Because of this, the 
OMG is providing their own bindings for the Corba environment.

BH: Do we have normative bindings through the OMG?

PLH: They do have mappings that are usable on the client side. But 
if you try to use this IDL (e.g., in C++), it's unusable. The OMG 
stuff is for client-server communication, not really for 
client-side. I recognize there are some use cases. But I think that 
Web services and other new technologies will obviate some of this; 
bits will be replaced by XML.

PLH: I have a couple of comments:

  a) On access to views - I recognize that this is necessary when
     you really want to know what's on the screen. But when you
     access the views content, you lose structure. In the best case,
     it will be a set of boxes. But clearly there are cases when you
     need to know what's on the screen. The DOM 3 Proposal for user
     formatting was trying to address this use case.

BH: It's not necessary for the view to be flat.

PLH: Yes, it can have some structure, but it may not have any
meaning. E.g., CSS absolute positioning will render some boxes
meaningless other than their position on the screen. Also, for SVG 
or X3D content, you don't even know how your rendering structure 
will be represented. So the term "rendering structure" is vague.

PLH: (b) Regarding the DOM and the problem between an invalid
document and the rendering structure - usually the parser does some

PLH: (c) I think it is important to distinguish between normative 
DOM bindings and non-normative. You should require DOM for 
Java/Ecmascript since that promotes interoperability.

RS: Yes, you need access to doc structure for more complex formats
like SVG. Even for non-normative bindings, DOM is important. I
understand that you will not have a standard C++ binding. Solve this
by requiring UA developers to document their DOM binding. But still
require the DOM API be implemented.

BH: What a sighted user interacts with is only implicit structure;
it's visual structure. This is obvious, but significant. What we are
aiming to do (at least what we hear blind users are asking for) is 
to know what's on the screen.

IJ questions: Is there anyone who thinks we *should not* have
a requirement for access to structure?

BH: I don't think it needs to be a P1 requirement. It's unclear to 
me how, in the general case, access to the DOM gives you what users 
want to know. Low vision, blind users want access to screen

JG: Our requirements are not to manipulate the DOM, but to give ATs
the means to perform functions through a standard API.

BH: Sighted users want to use the GUI that's on the screen.

PLH: I disagree with this; when I want to add a paragraph to my 
HTML, I would do this in a programming environment through 
structure, not a view.

DP: I think there's a piece missing in BH's scenario: What we have
here is an attempt to provide AT developers with a unified way to
provide information to the users of the AT. That information can be
provided in such as way as to allow a person to manipulate graphical
elements (whether handed to the AT by the UA's use of the DOM or 
some other method). What the user wants is the ability to interact 
with the content being delivered. What UAAG 1.0 tries to provide is 
a way to achieve this without AT vendors trying to invent a way to 
do it.

BH: There are APIs. New ones. The concern I have is that the DOM
doesn't help AT developers do what they need to do.

DP: AT developers are using the DOM and supplementing it.

PLH: I have a problem understanding why AT developers need access to

BH: This is about users using visual user agents more effectively --
off-the-shelf software.

JG: As we move forward, DOM access to XML will be more important 
(and XML content will be valid).

JG: Henter-Joyce looks at content (DOM) and can extract accesskey
information that is provided to user in a separate document.

DP: And heading-level information.

BH: Structure information is important, but what I think the user
really needs is a DOM for the view.

IJ: Balance between content / view access is what our proposal is.

BH: I'm still troubled by content requirement; big burden that
detracts from effort for providing access to view. I wouldn't want a
UA to not be able to conform, while providing structured view access
and streaming access.

PLH: Mozilla has DOM bindings in Linux.

BH: But you don't have a good way of exporting that out of process.

JE: We do both.

CL: We embed the browser control in the HPR process.

BH: Not the case with AT vendors we're working with. All going on
out-of-process. The goal is to have ATs working for the entire

IJ: We promote DOM specifically for Web content.

BH: As long as the need for view is recognized, I'm satisfied. But I
still feel that implementation will be a burden.

BH: 508 also puts a higher accent on identification of what needs to

  - Add a P1 view requirement.
  - Require DOM for access to XML/HTML
    content in java/ecmascript environments.

BH: For third point (non-normative bindings), we would prefer not
requiring following DOM and publishing DOM bindings.

PLH: I agree with BH on this (i.e., support JG/IJ proposal
and not RS's).

LRG: If someone has implemented the DOM, they have to do additional
work to expose the view information. Too bad these can't be tied
together. We've documented an API for access to rendered
information (MSAA). We'll probably do something similar to what
MS has done - tie MSAA and DOM together.

TL: IE exposes view information.

JE: Structured view information is more useful than just pixels. It 
is helpful when view information connects to the structure.

PLH: It's not always possible to map from rendering information to
structure. E.g., a document transformed through XSLT. No way to
guarantee mapping back to structure. Also, some style languages 
(e.g., css) add content; no way to connect that to a DOM constructor.

TL: The markup, regardless of format, can be accessed through an
interface, but it's not structured; it's a stream.

BH: When I say "structured view", I'm talking about something that's
not just pixels. You have a hierarchical object model with attributes.
There are cases where it's not difficult to give structured view
access. Frequently, in a UA, you have a content DOM, but the 
renderer looks at some intermediate format that is no longer the 
content DOM. Or, if the UA is using a standard set of building 
blocks (e.g., for displaying paragraphs, images, etc.), then the 
renderer can provide the same level of abstraction.

IJ: We could say "pixel access alone is not sufficient."

/* BH leaves */

PLH: Another problem of view-only access - there may be some cases
where someone wants access to something that's in content but not
rendered. In my opinion, having content without view information is
not a good idea. If I had to choose one, I would choose DOM over
the view access.

JG: Suppose I'm developing an XForms application. I may have to
retrieve a bunch of XML documents to understand how an xforms app is
rendering a form.

PLH: The only thing the DOM provides you by default is access to the
XML Infoset. If you have a schema attached to it, the DOM will not
give you access to the Schema. Yes, a generic application may need 
to download a series of XML documents. There is some discussion 
currently whether we should be able to access the result of the XML 
Schema validation (and not just the DOM). Being able to replicate an 
XML Schema validator is not something you would want an AT to have 
to do. But view information will not help solve some issues either.

JG summarizing: We have everything from wanting to know pixels to
knowing actual content coming down the pipe to the system. We need
to take back and look more closely at various needs of different 
types of ATs and browser technologies.

JG to CL: If you get XML content, what do you do with it?

CL: We convert everything to HTML first. We don't handle MS Office
content through the DOM. Just as a screen reader. We only handle 
HTML or text document in graphics view. We are having problems 
handling anything that's not HTML right now. We have different parts 
of HPR: we have a little screen reader that reads non-HTML. But we 
don't have a way (yet) of how to pass focus to these things.

JG: Have you explored working with Powerpoint?

CL: No.

PLH: I have some concerns with direction of UAWG: you can't evaluate
all use cases. If you have HTML+SMIL, you will want to have access 
to the timeline.

IJ: Today, we require access to UA functionality (e.g., to pause).

PLH: In the case of xforms, you'll want to access data types. And so
forth, for each type of XML application. If you go down this path,
you'll have to consider all types of XML applications and find use
cases for them, and require APIs for all of them.

JG: What if we have no example of an AT using DOM for access
to XML content? Does Henter-Joyce parse other types of XML? We heard
that HPR is not accessing XML content? We don't have an example
of ATs finding this useful today.

PLH: What about Adobe implementation of SVG? They provide DOM access
to SVG. People are accessing any kind of document through the DOM. 
The Adobe plug-in is one example.

JG: I just want to voice some concerns that we have requirements 
that some AT vendors are not finding useful. We know of many cases 
for HTML content where access to content is useful. We hope the same 
for XML, but haven't seen any implementations by AT developers. If 
we ask UA developers to do things, we want to be sure that there are 
people at the other end to receive the data.

IJ: Do other people feel like Jon that since we don't have
more XML experience, we shouldn't make any XML requirements
(through the DOM)?

DP: I suggest taking this to the list. From the survey we sent
to AT developers, I wonder how we can meet those needs.

IJ: We have heard resoundingly the need for access to content
(XML or not). We are only saying here that people should use
the very best API to promote interoperability. I realize that
there are CR issues (implementation experience).

JG: I just want to ensure that when we go to the Director,
we can say with confidence "AT developers want this, even if
they need to catch up."

Completed Action Items

IJ: Send proposal for Guideline 10 modifications based on today's
Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0081

IJ: Propose text to the UAWG on conformance profiles for use by other
Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0083

Open Action Items

IJ: Review UAAG 1.0 for which checkpoints should be "all formats" v.
"formats that are part of the claim".
Status: Pending.

JG: Write up user scenarios for why non-text-based highlighting 
for users; notably which users.
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
See for additional questions:

JG: Clarify why "Max rating" used in some cases (in low implementation
experience section) and "Avg rating" in some cases. Also, delete 
"+/-" with P (round down from G to P)

JG: Contact developers for API requirements

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Thursday, 16 May 2002 15:37:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:31 UTC