- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 31 May 2001 16:09:19 -0400
- To: w3c-wai-ua@w3.org
31 May 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0227
Minutes of previous meeting 30 May:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0224
Next meeting: 7 June.
Present: Jon Gunderson (Chair), Ian Jacobs (scribe), Charles
McCathieNevile, Aaron Smith (GWMicro), Glen Gordon
(Freedom-Scientific), Randy Marsden (Madentec), David Poehlman,
Harvey Bingham, Jim Allan, Mickey Quenzer, Hans Riesebos (Alva)
Loretta Guarino (Adobe), Denis Anson, Mark Nelson (AI-squared),
Rich Schwerdtfeger
After 90 minutes: Gregory Rosmaita
Absent: Tim Lacy
Regrets: Eric Hansen
Reference document 25 May 2001 Guidelines:
http://www.w3.org/WAI/UA/WD-UAAG10-20010525/
----------
Discussion
----------
0. Status report of UAAG 1.0
1. Changes in Guideline 6
IJ: Summarizes structure of document and API requirements.
---
DOM
---
JG: Are people using the DOM? Want to use the DOM? Which DOM?
GG: I am slightly confused because the IE DOM is not the W3C DOM.
JG: Microsoft has deprecated their proprietary stuff, and advise
people to adopt the W3C DOM.
GG: We are currently parsing HTML and building our own DOM. The
incentive to move to the W3C DOM has to be either more platforms
(e.g., Mozilla) or more features. If browsers implemented the DOM
then we would switch. If they build it into the browsers (and
there's a convincing business argument that we wish to support
those browsers), then we will switch.
GG: What is slow on behalf of Opera and Mozilla is that they
don't provide timely access.
JG: Refer to (GG's requirement) checkpoint 6.9: timely access.
HR: I cannot say too much about what we are doing, but we are
interesting in standardizing through the DOM and through XML. As
long as the DOM is not implemented cross-platform, we have
problems with it. We would be interested in using the
DOM. Checkpoints 6.1 and 6.2 are important checkpoints.
RM: Our company doesn't produce a screen reader. We are not
familiar with this work, and I don't think we're alone. We build
a head pointer, onscreen keyboards and cursor control software.
Our requirements are fewer than those of AT developers of
software for users with blindness. We are developing more for
mobility issues. We are interested in which behaviors are
attached to an element.
DA: Are behaviors attached to elements through the DOM?
IJ: Not all of them. Only those that are available in markup.
We've asked the DOM WG for the full list in a later version of
the DOM spec.
RM: In the mobility world, scanning the page is an issue. If
I'm a scanner, how do I get to a lot of links on a page?
JG: This information is available through the DOM.
DP: We have some requirements in the document for single-key
access (for mobility). We also encourage WCAG 1.0 authoring (so
accesskeys are available).
AS: Right now, the majority of our access to content is through
MSAA. If the browsers take off on DOM support, we will strongly
look into support for it.
LG: We use MSAA for communication with ATs. DOM may provide us
with the right kind of cross-platform solution (though obviously
not designed for PDF...). Cross-platform support is a strength of
PDF.
CMN: The Adobe SVG viewer implements the DOM.
MN: So far, we have been looking at the IE DOM. If the
W3C DOM were available, then we would use it.
----------------------------------------------------
Examples of APIs for access to non-HTML/XML content?
----------------------------------------------------
LG: We use MSAA for access to PDF.
CMN: Tagged PDF has structure. You could expose this information
through a DOM-like information.
LG: We can't use MSAA very well for exposing the structure
of some PDF documents.
HR: Is a Java applet considered content? We use the Java
accessibility API.
GG: We are using the APIs of Word and Excel for their content.
These are exported through the COM interface.
IJ: How many APIs do you have to implement in order to support
IE, Word, Excel, etc.? Do you have to re-implement everything
each time?
GG: Whoever does the mapping from the internal model to MSAA has
to make trade-offs. MSAA isn't rich enough to provide all the
access to content that one would want.
/* GG leaves */
RM: We suffer from legacy code problems, and backwards
compatibility. We have to rely on hooks. That's what spawned
MSAA. But we often have to go to a low level for some
information.
JG: Some of our reviewers have said that MSAA is not enough, so
they've had to develop a separate API.
JG: I hear people saying that MSAA is not a cure-all for
providing accessibility.
RM: MSAA is a steop in the right direction, but there are things
we have to do ourselves.
JG: So, people will probably continue to need APIs in addition to
MSAA.
RM: I think that there are two levels: the MSAA-type access to os
information, then markup access at the DOM level.
RM: E.g., MSAA doesn't give me access to content in a window
readily. We still rely on other APIs for this.
LG: Acrobat is using MSAA to communicate that type of
information.
-----------------------------------
Access to user agent user interface
Are custom APIs required?
-----------------------------------
HR: We use MSAA for access to user interface. In the long
run, interoperability is more important, but we are also looking
for short-term solutions. I'm not sure which way is the best way
to go for UAAG 1.0.
AS: We stick with MSAA because it's the most popular and we've
used it the longest. We're not opposed to using APIs if they are
available.
IJ: MSAA is designed for interoperability with ATs, so it
satisfies our checkpoints.
IJ: Any non-MSAA experience to report?
/* No comments */
DA: To what extent is MSAA supported by non-Microsoft
applications?
RS: Lotus Notes 5
LG: Acrobat
CMN: What does Notes support for access on other platforms?
RS: None. One of the problems is that there isn't an pre-defined
accessibility structure on other platforms (yet).
JG: Hans, how do you work on the Mac?
HR: We hack into the system. There are not dedicated APIs.
IJ: Do you consider the system calls an API?
HR: Yes.
IJ: Should a browser in this case be allowed to conform? It's
not doing anything. ATs are only tapping into it for information.
JG: Well, if the user agent developer documents how access is
possible, this would probably be ok.
HR: We were not really "informed" about how to tap into the
system on the Mac. I don't think that it's sufficient for a user
agent developer to conform by allowing an AT to hack into the
system calls.
JG: I think that developers would have to do more than they are
doing today, but maybe not much more.
RM: I think that on the Mac, the AT developers tell Apple how
they are hacking their way in. So typically, documentation is
from the AT developer, not Apple. Unless something has changed,
there's nothing official from Apple saying how to hook into the
system.
JG: If we take away the option of using system calls, then
there's not any way for a user agent to conform on the Mac, or on
a Unix platform.
RS: I'm concerned about 6.4 (not emphasizing MSAA or other
operating environment APIs first).
RM: I agree. I don't want to have to implement N APIs, even
though designed for interoperability.
IJ: I note that the 25 May draft does not depart substantially
from previous requirements; we never *required* a specific
operating environment API for conformance.
JG: Some people want to conform even though they don't want
to use MSAA.
RS: We should not let application vendors create their own API.
CMN: What about the DOM for cross-platform applications?
RM: The Microsoft Office people have implemented their own API
and have been "on our case" to implement their API, and their
part of Microsoft! In practice, APIs don't have resources to
support more than a few APIs.
IJ: There are a couple of issues here:
- We never required implementation of an OS API specifically
because of cross-platform cases (e.g., Mozilla). So the DOM
was considered good enough for the user interface.
- Also, we did not want to attach conformance to UAAG
necessarily to a particular vendor's API. Therefore, we did
not want to require *only* conformance to the conventional
operating environment APIs.
RS: I distinguish MSAA as an industry standard from other
proprietary APIs.
JG: We've had reports that MSAA is not doing the job
for some developers.
RS: People should use MSAA with other mechanisms to provide
access.
/* IJ reads checkpoint 6.4 */
JG: The criterion is that the API is designed for
interoperability.
IJ: Even in the case where a custom API promotes interoperability
and is good, it is another API.
RM: And that's a problem.
AS: A lot will be driven by the market. If someone develops a
great API, and users want it, we are likely to implement it.
CMN: But that takes time (for ATs to implement).
JG: Users probably don't know about APIs.
AS: But users do know about products they want to use, and
whether there is support for that product.
IJ: It sounds like some people are saying, in essence, that
you have to implement MSAA to satisfy UAAG 1.0.
RS: I would argue that the DOM has not been tested for access
to GUI controls.
MQ: From the input today, we are getting confirmation that AT
vendors require MSAA.
IJ: But we should not limit conformance to MSAA.
RM: MSAA is designed to go with Windows. If you say "support the
api designed for the operating system", then that seems
sufficient. Doesn't this have to be done by the vendor?
CMN: No. Consider an open software enviornment like Unix. There
are several APIs in development.
RM: So closed and open operating systems are different cases.
RM: I agree with the suggestion to have a cascade where the
operating environment API comes first.
GR: What worries me as an end user: there are things like the
Java access bridge by Sun, which is minimally supported and
documented. This is an API that includes interoperability
features, and is not MSAA (but runs under Windows).
RS: "If the operating environment supports an accessibility
API, support at least this."
IJ: I propose instead a very strong emphasis on the operating
environment conventions, rather than making this a requirement.
IJ: I hear people saying that we might distinguish cross-platform
user agents from single-environment user agents.
RS: If you have a cross-platform solution, in the absense of an
OS-specific API, you can use the DOM, for example.
LR: We started with a platform-API and added extensions.
RS: I would feel comfortable with the proposal to allow the DOM
if there were some screen-reader vendor, for example, with access
to controls through the DOM.
JG: We can ask Netscape (or others) to do this during Candidate
Recommendation.
GR: Yes, I think that buy-in is important.
Straw poll:
- Must implement operating environment standard API first:
Rich, Randy, Aaron
- Allow implementation of other APIs that promote interoperability:
Hans
- In-between: Loretta.
No Resolution.
---------------------
[Continued] Open action items
---------------------
1.IJ: Coordinate usability testing of the guidelines (JRG volunteers to
be one of the testers).
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137
5.RS: Send pointer to information about universal access gateway to the
WG.
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258
6.GR: Review event checkpoints for techniques
7.GR: Rewrite different markup (list of elements) that 2.9 applies to,
for clarification.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 31 May 2001 16:09:25 UTC