- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 16 May 2001 16:10:47 -0400
- To: w3c-wai-ua@w3.org
16 May 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0152
Reference document 11 April 2001 Guidelines:
http://www.w3.org/WAI/UA/WD-UAAG10-20010411/
Minutes of previous meeting 10 May:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0127
Next meetings:
May 17, 18 (extra)
Present:
Jon Gunderson (Chair), Ian Jacobs (scribe), David Poehlman,
Denis Anson, Scott Totman, Jim Allan, Gregory Rosmaita, Tim Lacy
Absent: Mickey Quenzer, Rich Schwerdtfeger, Eric Hansen
Regrets: Harvey Bingham
Also HB regrets for 23 May.
-------------
Announcements
-------------
- Please review teleconference schedule on WG home page.
There is information about the teleconferences May 17, 18,
23, 24, and 25.
- Next draft of Techniques will have a "Who benefits" entry for
every checkpoint. I will ask people to review those paragraphs
specifically.
- Check out Gregory's test pages:
http://www.hicom.net/~oedipus/wai/ua/tests/index.html
/* We do introductions since this is ST's first UAWG
teleconference */
--------------
Discussion
--------------
---------------------------
Issue #469: Write access to controls that can be changed through
the user interface.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0068
Proposal: For harmony with checkpoint 6.1 (DOM write access):
a) Split 6.3 into read and write, with write access only for
what can be done through the UI.
b) Split 6.4 into read and write, with write access only for
what can be done through the UI.
ST: That would satisfy me.
JG: Do we have examples of UI control values that the user would
not be able to change through the UI?
ST: We have a control that simulates HTML and is for display
only. The user should not be able to write to those values.
TL: That's pretty much what we do. We may have editable controls
that are not editable until they become visible. You might have
an editable property whose visibility property is hidden.
Resolved: Accept proposal.
---------------------------
Issue #470: Navigation to disabled active elements
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0068
Proposal:
- Clarify definition of enabled/disabled/interactive elements.
Refer to IJ's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0073
- State that the assumption of this document is that the content
focus always designates zero or one enabled or disabled elements
(but never non-interactive elements).
- No change to checkpoint 9.6, but mention in techniques that a
configuration option to include disabled elements (for reasons
cited by Scott) is fine.
- Revise definition of focus to set expectations for it. Also
mention that a "caret", while it takes keyboard input and is
stateful, is not generally used to activate enabled elements and
so is not what we are talking about.
Resolved: Accept proposal.
---------------------------
Issue #471: Standard versus proprietary APIs for compatibility with
assistive technology
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0068
See Rich's defense (supported by Tim):
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0132
JG: Why didn't MSAA suffice?
ST: Our client predates it. Most of the ATs we work with predate
it as well. MSAA is used strongly for Web activities, but for
good old Windows apps, not all ATs use them.
JG: Our main concern is to promote interoperability. A lot of AT
developers don't have resources to develop specialized APIs.
Therefore, I think UAAG should probably not promote proprietary
APIs as that may not stand the test of time. It sounds like you
are saying that MSAA could be used, but reimplementation would be
necessary.
ST: I don't think we will rework MSAA into the Windows portion of
our application. I can see integrating it into our browser. I
don't think most ATs have integrated it into the Windows portion
of their software.
TL: I recognize what ST is saying. The initial implementations of
MSAA left a lot to be desired. I know of several AT vendors that
the IE Team works with to implement MSAA correctly and to get it
working to their satisfaction. What I am concerned with by
following the proprietary model is that AT vendors will have to
write "monstrous case statements" to select from available
APIs. I don't think that this direction benefits AT developers or
users.
ST: I think that Jaws would fail this requirement because it
doesn't use std APIs for every feature.
IJ: Let's distinguish:
a) Deployed software
b) Inadequate API issue
c) Will ATs actually use it?
GR: Should include rationale as well when an API doesn't
meet needs.
IJ: That's a lower priority requirement, as long as the API has
been documented.
DP: AOL has to deal with browsers AND Windows applications. ST
said he could see implementing MSAA in the UA.
ST: This UA/non-UA line can be fuzzy in the AOL client.
DA: I think it would be frustrating for the end user to have only
part of an application that conforms.
ST: We use another internal markup language (FDO) for parts of
the application outside the browser.
ST: Would you consider an instant messaging system a user agent?
JG: We wouldn't exclude it, but we haven't considered issues
raised by such a technology. The farther you move away from the
model we've considered, the fewer checkpoints will apply.
ST: I think that the vendors we work with don't use MSAA.
TL (to ST): MSAA aside, does the viewer window implemented by the
AOL client have a published API?
ST: Yes, standard windows calls (e.g., get text). Our custom
controls now respond to calls used by assistive technologies.
TL: From an interoperability standpoint, the thing that concerns
me from a user's standpoint: if I want AOL, and I'm restricted to
one or a small subset of AT vendors to get it, that would bother
me. An unpublished API is problematic.
TL: Is it correct to say that I could use AOL with several
vendors?
ST: Yes.
ST: For Jaws, we use Jaws scripts (they have a scripting
language). I write scripts for my client that Jaws
interprets. Is that a problem? Or would that be considered a
standard API?
DP: I think most AT vendors provide a similar mechanism for
better interaction. If only one or two vendors are capable of
providing an interface, is that because the other vendors don't
have a way of interacting?
GR: I think that the scripting files and set files are
intermediate steps, but not the standard API.
IJ: I don't think that Jaws scripts would be considered a
standard API; it's pretty proprietary. On the other hand, I would
consider MSAA the de facto standard on Windows. So we should
probably be more specific about what we are expecting.
/* TL drops off */
IJ:
a) Deployed software: I don't think this should cause
us to change our document.
b) Inadequate API issue: I think we can address this
c) Will ATs actually use it?: I think we need more AT input.
Action JG: Talk to AT vendors (e.g., on the list)
about use of standard APIs.
GR: AT developers I've talked to have said that if browsers used
standards they would code to it. I think UAAG 1.0 needs to take
the lead to promote standards.
JG: We need to stop the pattern of kludges to satisfy
accessibility requirements.
Resolved:
a) Leave the primacy of standard APIs in the document.
Do not allow conformance simply to "better APIs".
b) For checkpoints 6.3-6.5 and 6.7, make the following consistent
with 6.6: If std API not available or does not allow the UA to
satisfy the requirements of the document, use a publicly
documented API.
/* ST leaves */
DP: I have some concerns about the second sentence. A few years
ago, a screen reader called ISIS cost more than the software it
ran on. In order to do anything useful, you had to have a second
screen reader. I don't want a market where a UA can conform but
not really interoperate, or where some AT vendors are put at a
disadvantage.
IJ: I think that the situation would be the same anyway, but
we're just asking that the API be public. That seems to be an
improvement.
JG: I don't know who will make the decision whether someone's
publicly documented API is really better than something like
MSAA.
IJ: We are distinguishing:
- If the API is broken: allow people to conform and work around it.
- If someone can do better, we don't allow conformance
for better, but non-standard APIs.
c) Include in well-formed claim a requirement which APIs
are being used to satisfy Guideline 6 (since interoperability
important). [Should include some rationale if non-standard
API is used.]
d) For checkpoints 6.3-6.8, change to "at least one standard
API".
---------------------------
IJ: We still have the outstanding question of what we accept as a
standard API. Glossary states:
"As part of encouraging interoperability, this document
recommends using standard APIs where possible, although this
document does not define in all cases how those APIs are
standardized (i.e., whether they are defined by specifications
such as W3C Recommendations, defined by an operating
environment vendor, de facto standards, etc.)."
JG: Some characteristics:
a) Publicly documented
b) More than one AT be able to use it ("reusable by other
ATs").
/* Denis leaves */
IJ: Cascade:
a) Use standard API (where std means W3C Rec or public
product of another stds organization).
b) If no std API exists or is broken, use a public API
that enables interoperability (i.e., not be limited
to communication with only one specific assistive tech).
GR: WindowEyes and HAL offer MSSA-mode and non-MSAA mode.
JG: Jaws uses MSAA for some things and not others.
Action IJ: Write up a proposal for the cascade of APIs:
- Standard first (more strictly defined)
- Public reusable API next.
- Requirement for at least one accessibility APIs covered by
6.5. (see issue 472).
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0105
[6.7 is a special case since talks about OE specifically.]
Proposed language for 6.6:
6.6 Implement at least one (standard?) API (e.g., of the
operating environment) designed to benefit accessibility and
allow interoperability with assistive technologies.
Action IJ: Include this as part of previous action.
---------------------------
Issue #475: Checkpoint 2.9: Does this checkpoint mean auto rendering of
all
content in same viewport?
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0073
Resolved: State that to satisfy 2.9, the user agent must allow
configuration to render all conditional content automatically,
but that this may be done at different time in different
viewports. [Indeed, it is probably a big mistake to render
everything at once in the same viewport.]
---------------------------
Issue #478 4.9: Clarify that global volume control can
cover content and UI controls
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0073
Resolved:
- For 4.9: It's ok if the technique also allows control of UI
control volume.
- Add to the Conformance section something like:
"For the purposes of conformance, for those requirements
that are "Content only" but that also have manifestations
in user agent features, a technique that satisfies both
Content and user agent features will satisfy the checkpoint
except where the checkpoint explicitly states the
contrary."
In short: Content only is a minimal requirement.
-----------------
Completed Action Items
-----------------
GR: Screen shot of Lynx for refresh, and redirect.
done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0123
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0125
GR: Will send test pages to list
Source: http://www.w3.org/WAI/UA/2001/05/wai-ua-telecon-20010503
Done:
-----------------
Open Action Items
-----------------
IJ: Edit the text of checkpoints 2.1, 2.2, 8.1, and 8.2 so that UAs are
not
required to conform for all formats that are implemented.
Source: Minutes 19 April 2001 Teleconference
IJ: Make mention of animations, text streams, and refresh in the
document.
Source: Minutes 19 April 2001 Teleconference
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
RS: Send pointer to information about universal access gateway to the
WG.
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258
GR: Review event checkpoints for techniques
GR: write different markup (list of elements) that 2.9 applies to, for
clarification.
CMN: Find out from SYMM WG whether repositioning of objects will appear
in
the spec (or should be in UAAG).
Source:http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0357
MQ: Review speech checkpoint techniques document
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Wednesday, 16 May 2001 16:10:49 UTC