- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 16 May 2002 15:35:01 -0400
- To: w3c-wai-ua@w3.org
UAWG teleconference, 16 May 2002
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0089
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
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0080
Next meeting: 23 May, 2pm ET.
Regrets: Harvey (next 2 weeks)
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
==========
Discussion
==========
1. Issue 529: 6.1, 6.2: Is DOM required at P1, or some API?
http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html#529
See proposed resolution of issue 529:
http://www.w3.org/WAI/UA/2002/04/api-summary
(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
repair.
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
information.
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
views.
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
desktop.
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
provided.
Resolved:
- 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
teleconference
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
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
specifcations.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
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".
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049
Status: Pending.
JG: Write up user scenarios for why non-text-based highlighting
important
for users; notably which users.
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027
See for additional questions:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0029
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)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049
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