- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 01 Feb 2001 16:02:09 -0500
- To: w3c-wai-ua@w3.org
1 February 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0180.html
Minutes of previous meeting 25 January:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html
Next meeting: 8 February
Present:
Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, David Poehlman,
Eric Hansen, Jim Allan, Al Gilman, Tim Lacy, Rich Schwerdtfeger
Regrets:
Denis Anson, Kitch Barnicle, Charles McCathieNevile, Gregory Rosmaita
Absent:
Mickey Quenzer
------
AGENDA
------
1.All working group meeting coordination
JG: Who would like to attend by phone: DP, JA
JG: Who has registered: HB, IJ, JG, AG.
AG: I don't a black and white plan.
IJ: I think RS and GR will be there.
EH: I hope to be there, unsure though. I would be able to
attend by phone part of the time.
TL: I keep asking for MS attendees, but no one has stepped up
yet. I could attend part of meetings by phone.
Action JG: Ping AOL to see if they can attend.
Action JG: Request bridge from Judy for 3-4 people. [No guarantee]
---------------
Tim Lacy on Balloon Tips
TL: I have a question about using "Balloon Tips" instead of
dialogs. The problem is that they don't send focus events. If they
did, would screen readers pick up that event? The problem is that
there's no focusable thing inside a balloon tips window.
JG: Can't MSAA send a change event?
TL: MSAA has the text in the balloon tips, but that class of window
can't send a focus event. MSAA would have to proxy it for them.
I have suggested not doing balloon tips.
DP: Tool tips are available to screen readers that know to look for
them. I think MSAA plays a role in this.
AG: People who can help with this: Rich Schwerdtfeger and others
on the side of catching the events. I suggest writing this problem
to the list. The DOM people will probably have a proper event for
this. We need to get this into our heap of issues for accessible
scripts. The UA needs to throw an event that can be caught by
ATs. The problem is for tools outside the Web sphere.
/* RS joins here */
TL: Since a balloon tip has nothing focusable, what's the best
way to alert the AT? MSAA may already provide partial support.
AG: This is an exception case...Look in vhdl for
"Note/Warning/Error/Failure"
TL: The Balloon is created by an event, and that's where you should
alert the AT.
AG: And that's where you classify them: so that the AT can pay
attention to only some of them. Source should grade events,
AT should filter them.
/* AG leaves, and asks for clarifications to Al's proposal by email */
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0189.html
2.Issue 455: Guideline 4: Change to "Ensure user control of
presentation"?
Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#455
JA: "Presentation" is fine.
IJ: "Rendering and behavior"?
JA: G4 prose is mostly about presentations.
IJ: G4 is mostly about controlling behavior/rendering that can be
detrimental. G4 is about content rendering and viewport
behavior.
Resolved: Change G4 to "Rendering and viewport behavoir"
3.Issue 456: Editorial: Need to clarify in section 3.2 that we do not
mean system APIs
Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#456
Resolved:
1) The old section 3.2 did not require this.
2) The revised document no longer suggests that this is required.
3) Checkpoint 5.6 (26 Jan 2001) requires standard APIs.e
4) The WG does not think that if an standard API does not exist,
that the UA has to implement a proprietary API.
5) If a standard device API doesn't exist, it's probably not an
environment we are trying to address with this environment.
4.Issue 457: Checkpoint 5.4: Ambiguity about what exactly required:
standard APIs only?
Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#457
"Checkpoint 5.4: Provide programmatic read and write access to user
agent user interface controls using standard APIs (e.g.,
platform-independent APIs such as the W3C DOM; standard APIs defined
for a specific operating system; and conventions for programming
languages, plug-ins, virtual machine environments, etc.)"
IJ: Question: If there is no standard API, must you still provide
access to UI controls?
RS: I don't think so; the platform is "inaccessible".
DP: I read it differently: providing access came first, then
using standard APIs came second.
IJ: Must you still provide access to custom controls.
JG, TL: Yes.
Proposed:
a) Provide programmatic read and write access to user
agent user interface controls.
b) Where a standard API exists, the UA must use it.
c) Add clarification that access required even where standard
API not available. You should implement accessibility APIs
in your controls to provide access. This works for Java and
MSAA.
IJ: Can custom controls be subclasses of standard controls?
TL: Yes.
JG: There are some cases (e.g., in MSAA) to create custom controls
using accessibility APIs.
RS: In the java case, you can provide a list of action
description pairs to an element.
TL: Here's an example: you can put an ActiveX control in a Web
site. It's easy to write one that is a black hole to ATs.
If you write one that uses MSAA, you've created a custom
control, but you've implemented the standard accessibility
API for it.
DP: I'd hate to exclude potential future technologies from being
able to claim conformance. If a UA can provide an accessible
solution, they shouldn't be excluded from conformance.
Straw poll:
Allow conformance without using a std API: IJ, DP, EH, RS
Don't allow conformance without using a std API: TL, JG
Abstain: HB, JA
Resolved:
a) Drop "using STD APIs" from 5.4
b) Add cross-reference to 5.6, since it covers the standard
API requirements.
c) Checkpoint 5.4 requires read-write access in all cases,
even when no std APIs available.
5.Issue 458: Do link highlighting requirements apply to all zones of an
image map?
What is required granularity?
Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#458
IJ: The issue is, e.g., an image map.
DP: Is this visual highlighting only? If I activate an image map,
using MSAA and IE+Jaws, I get links from inside the image map.
IJ: I am happy to live with the granularity of "whole image map"
since I assume that the hot spots are conveyed through the image.
RS: The API should give you access to each link in the map,
independent of what's in the image.
JA: Form controls are distinctive; that highlights them.
JA: I think highlighting the image map as a whole is sufficient.
/* RS and TL leave */
Straw poll:
Image map as a whole suffices: JA, DP, HB
Individual hot spots required: CMN (by email)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0181.html
Resolved:
a) Add a note to 8.3 that highlighting an image map as a whole
satisfies the checkpoint for image maps. UA may highlight
all of the hot spots of a client-side map.
b) There is some assumption that the author will make the image
communicate different zones. We choose not to add a repair
requirement for the case of bad images.
6.Issue 443: Checkpoint 1.4: Device independent access to pointer
(mouse)
specific events.
Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#443
Status: The document currently requires emulation of mouse-specific
controls by virtue of our requirement that the user must be able to do
everything through the mouse.
IJ: Note that 1.1. states:
"Ensure that the user can operate the user agent fully through
keyboard alone..."
IJ: This implies that the user agent must repair device-specific
behavior specified by the author (e.g., the mouse).
This is related to issue 370 raised by Phill Jenkins
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#370
IJ:Do we want to require the UA to repair device-specific bindings
specified by the author? Do we have evidence that the ability to
simulate mouse events through the keyboard benefits the user?
IJ: I could see going two ways here:
a) Bad authoring requires repair by UA and we don't require 1.1
b) No exceptions to 1.1 (repaire required for mouse-specific events).
DP: I could see taking device-specific events for 1.1.
Straw poll:
a) We must include in 1.1 coverage of
author-specified device-specific behavior,
and call that out as bad authoring: JA, HB
b) It is ok to exclude from 1.1 author-specified device-specific
behavior, and call that out as bad authoring: DP, EH, JG
c) Abstain: IJ
JG: My main concern is that we don't have implementation
experience. We know they can't do some things, but we don't
have evidence that they would be able to these things.
IJ: We agree that this is a repair function. Repair of either
bad authoring or bad specs.
JA: Often this is done through JavaScript.
Resolved:
a) If we leave as is (no exclusion), add a note that this checkpoint
also includes repair of device-specific behavior specified by the
author.
JG: Leave open to get developer input.
Action IJ: Send email to list asking for input on this.
7.Definition Issues:
1.Issue 359: Definition: text content (incompatible with WCAG?)
2.Issue 358: Definition: Equivalent
3.Issue 322: The definition of the word element
4.Issue 321: Equivalency relationships and the wording
of checkpoint 2.3
IJ: Update: we have moved from definitions to scope of 2.3.
AG: We are close to being closed.
----------------
Completed Action Items
----------------
4.JG: Send screen shots of directional techniques
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0192.html
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0083.html
----------------
Open Action Items
----------------
1.IJ, EH, AG: Propose new definitions forterms in question
(equivalence, text element, etc.)
Status: Progress!
2.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.html
3.JG: Talk to Al Gilman at the next WAI CG meeting about a joint
meeting with UA, PF, and Voice WG (or participants) to discuss
accessibility issues.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0083.html
5.JG: Implementation information for guideline 2
6.JG: Propose text for the techniques document about synthesized speech
implementation issues. Notably UA and AT wanting to use the same
synthesizer
engine.
7.JG: Create issue list for things that need to be addressed in the
next version of the document
8.JG: Request input on the resolution of issue 454
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0105.html
9.GL: Ask someone from Microsoft whether they will evaluate the
guidelines with a product.
Deadline: one week.
Source:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html
10.GR: Review checkpoints in Guideline 10 for implementation information
11.JA: Review checkpoints in Guideline 4 for implementation information
12.MQ: Send more details about control of speech parameters for the
techniques document based on OpenBook. (deadline open)
13.KB: Submit technique on providing information on current item and
number of items in search
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 1 February 2001 16:02:12 UTC