- From: Ian B. Jacobs <ij@w3.org>
- Date: Fri, 19 Apr 2002 11:21:44 -0400
- To: w3c-wai-ua@w3.org
[Possible duplicate sent]
UAWG teleconference, 18 Apr 2002
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0053
Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe),
Harvey Bingham, Jim Allan, David Poehlman, Rich Schwerdtfeger,
Eric Hansen, Tim Lacy
Previous meeting: 11 April 2002
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049
Next meeting: 25 April, 2pm ET.
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
==========
Discussion
==========
Issues:
http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html
-----------
Issue #519:
Can DOM API requirements be satisfied if APIs are
not available out of process?
RS: Someone needs to write a bridge layer (that has to be thread
safe); either AT or communication framework.
RS: I think the answer to AL's question is "Yes, as long as it's
documented how this is done." When you access in process or
out-of-process, communication has to be thread-safe. Consider IE;
all the brokering is handled by the COM layer (sync, etc.). You
shouldn't be running into thread-safety problems.
TL: The big advantage you get with COM is that it handles
all the marshalling and other delegation.
RS: Another scenario - consider GNOME. They are creating a bridge
level to support and AT service provider layer in GNOME. The
service provider layer is CORBA based, which does the
marshalling for you. This allows you to access out of process. In
the case of GNOME, someone has to write the bridge. This could be
done by the AT vendor (e.g., by running in process using a
mechanism provided by, say, Netscape). As long as the methods can
be implemented in a thread-safe manner (e.g., using semaphores),
should be ok. AT can do caching or write to service provider
layer. The question is who implements the bridge.
RS: AT vendor may choose to do caching in process for performance
reasons. How this is done is up to the AT vendor.
RS: I think that as long as it's documented how to communicate,
and if the mechanism is thread-safe, whether in process or out,
this should promote interoperability between the UA and the AT.
RESOLVED:
a) In-process exporting is sufficient.
Action IJ:
a) Add a note to 12.2 (documentation) to remind people that
APIs benefit accessibility.
b) Update techniques document with RS text:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0055
RS: In terms of functionality, we should suggest thread-safety
for all APIs. Say that in the techniques document.
-----------
Issue #529:
6.1, 6.2: Is DOM required at P1, or some API?
IJ summarizes situation where AT developers are saying
that DOM not meeting their needs.
RS: AT vendors (especially on Windows) are writing to a mountain
of different APIs. E.g., on Windows you have MSAA, offscreen
model, DOM interfaces for excel, word, etc. More APIs requires
time, lots of work. The right solution is to fix the API set.
IJ: But we are hearing that AT developers are not jumping
at the opportunity to implement the DOM.
RS: That's because DOM API requirements unfortunately not
adapted to AT developer needs.
IJ: That supports the thesis that they shouldn't be required to
implement something that's not helping them. See JG summary of
teleconf with AT developers:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0123
JG: As the DOM is being used more and more for XML, the validity
of the content won't be as big a problem. Some AT developers want
repaired content to be available through the DOM, others don't
care and want to do their own repair. For, say, proprietary DTDs,
how will mapping between content and rendering be standardized?
DP: Does the feedback we got from AT developers help at all here?
IJ: Yes. Suggests full infoset desireable. But we don't have any
requirements for mapping from content to rendering structure. DOM
WG has discontinued its views work.
RS: We need to take this back to the PF WG.
Summarizing:
* Tension between API that works and too many APIs
(i.e., not standard that works)
* Take issue back to DOM WG if APIs are not sufficient.
RS: Why isn't the W3C standardizing APIs that will support ATs.
The DOM should be extended to include the needs identified by
AT developers.
RS: I don't support UAAG 1.0 going out with abstract
techniques to band-aid the situation. You should require
the DOM and extend it to meet the needs of AT developers.
JG: We have a couple of paths here:
1) Current path is that we wanted to lead with the DOM,
a cross-platform standard for access to HTML and XML
content. But we've heard some AT developers have had
success with DOM, and others not (since information
through DOM not representative of what's on the screen).
RS: The latter part is an implementation detail.
2) Provide access to a standard set of information through
APIs perhaps other than the DOM.
DP: For the purposes of moving UAAG 1.0, a well-written
proposal would be a good idea. I have had offline discussions
with vendors and industry players and have encountered serious
issues with the single API approach in the current document.
DP: (NEW) There is also an initiative underway within the ATIA to
develop a cross-platform specification for application
interfaces; directly to benefit ATs. This is outside of W3C, but
will be worked on; this might be a good opportunity for W3C to
work within that process to ensure that it's the right spec.
JA, HB: Won't be implementing the DOM, don't feel qualified to
offer opinion here.
DP: I support IJ's verbal proposal:
a) Infoset requirement (P1).
b) DOM for Java/Ecmascript
c) Best API otherwise, with DOM sufficient but not required.
TL: I don't think we will solve problem of multiple APIs. But I
agree that throwing it over the wall won't help the situation
either. Internally, I think we have four different COM interfaces
that go straight to the DOM in IE.
IJ: How does IE work in terms of document object and broken
content? Does IE fix it and then generate rendering from fixed
content?
TL: Rendering is based on incoming stream of bits. Document
object may be repaired and may be corrupted (the data model is
corrupt). The document object may not reflect what's rendered.
RS: Is the MSAA interface accurate w.r.t. what's rendered?
TL: Yes, it's accurate, but the MSAA tree may not include
everything that was rendered. It's a subset of the document
object, and should be correct with respect to the incoming
stream.
RS: I think that AT developers will have the same disconnect
between doc tree and rendered structure whether they use MSAA or
the DOM.
RL: Every element in the MSAA tree should accurately represent
the related portions of the rendering structure.
JG: So I am hearing that AT developers aren't at the W3C table
enough to get their requirements into W3C specs. There has been
more of a relationship between AT developers and Microsoft, for
example. Doesn't sound like W3C is the place where AT developers
are coming to develop the standard interface. How can we bring
them to the table or support the other groups working on this?
RS: Right now I think that W3C is the place to do this work.
RS: I suggest requiring the DOM and for those needs that the
DOM doesn't satisfy, allowing application providers to use
other APIs. People are using the DOM, but also other APIs for
information they aren't getting through the DOM.
TL: Yes, we saw that so much, we included round-tripping between
DOM and MSAA.
RS: I think that the bulk of the problems AT developers are
having is due to bad content. This is not a DOM problem.
TL: Yes, yes, yes, yes, yes.
RS: I don't want to put burden on UA of having repaired content
perfectly match what is rendered.
JG: AT developers are repeating what they have said all along:
their requirements are more than what the DOM provides
today. Therefore, we can proceed with:
a) No change to the document: P1 for DOM.
b) Two requirements:
1) P1 to provide access to "stuff". DOM is sufficient
and recommended.
2) P2 to use DOM.
Straw poll:
Support for a) RS, JA, TL
Support for b) IJ, EH, HB, DP, JG
JG: I have concerns that our decision will be arbitrary since we
haven't had AT developers at the table enough. I am towards DOM
as P2 requirement knowing its limitations. At this point, it
doesn't look like we have a process in place for getting more
buy-in from AT developers.
RS: AT developers said they needed DOM extended to make it more
useful.
JG: If they aren't interested in DOM as part of the solution, why
should we force it on AT developers?
RS: Why should we be listening to their requirements if they are
not willing to get involved in the process?
JG: I suggest that IJ and JG take this to the Director when
we talk about moving forward.
NO DECISION
======================
Completed Action Items
======================
HB: Find out what SVG WG is doing these days in the way of test suites,
and find out how to get UAAG 1.0 requirements incorporated.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049.html
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.html
======================
Open 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.html
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.html
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.html
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.html
See for additional questions:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0029.html
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.html
ALL: Send to the WG the top 5 things you need through an API.
Deadline: 4 April 2002
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Friday, 19 April 2002 11:22:17 UTC