- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 20 Oct 1999 13:37:57 -0400
- To: w3c-wai-ua@w3.org
User Agent Accessibility Guidelines WG Teleconference
20 October 1999
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita
Harvey Bingham
Kitch Barnicle
Charles McCathieNevile
Marja Koivunen
Rich Schwerdtfeger
Regrets:
Mark Novak
Dick Brown
Wilson Craig
Denis Anson
Agenda [1]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0116.html
1) Review of action items:
1.IJ: Follow up with Lake on usability questions related
to her posting [2] to IG.
Status: Done. I called her and we discussed a number of
features. She will send info to the WG.
[2] http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0023.html
2.IJ: Repropose Guideline 7 descriptive text to include
more than just W3C technologies.
Status: Not done.
3.IJ: Update document based on resolutions at F2F meeting
Status: Pending.
4.IJ: Redesign techniques document based on discussions at F2F
meeting
Status: Not done.
IJ: I haven't had time to work on this yet. It will be
essentially what we discussed at the FTF.
5.IJ: Propose on the list: Generalize 3.8 to apply to more
than just continuous tracks : all sources of alt content.
Status: Not done.
6.IJ: Add a checkpoint to turn on/off background sounds.
Status: Not done.
7.IJ: Propose how the conformance checklist will be delivered
Status: Pending.
8.JG: Announce F2F meeting being organized for December on
the UA page and list.
Status: Done.
9.JG: Contact MR about SMIL techniques
Status: Done. MR (Madeleine Rothberg) will send.
10.JG: Talk to Wilson Craig off-line about contacts for assistive
technology developers who may be interested in reviewing the document
during last call
Status: Not done.
11.JG: Ensure that December F2F meeting is discussed at next
telecon.
Status: Done.
12.JB: Follow up on hosting possibilities for December F2F meeting.
Status: Done.
13.HR: Find information about European contacts who may be interested
in
reviewing the document during last call
Status: ?
14.TL: Get feedback from MS IE Team on usability of 5 October
Techniques
structure.
Status: ?
15.GR: Write a proposal to address issues about spawned windows.
Status: Pending.
16.GR: Repropose Checkpoint 2.5 on user defined keyboard bindings so
that it's clear that there should be a cascade order whereby
the user has ultimate control or can concede control to the tool.
Status: GR did thinking out loud on PF list. Took the pulse
there. Should something be fixed in UA or elsewhere?
17.MN: Propose a new definition of active element, based on keyboard
navigation discussion at F2F meeting
Status: ?
19.CMN: Write a proposal to address this checkpoint 2.3 Provide
information to the user about author-specified keyboard
configurations. P3
Status: Pending.
20.RS: Propose rewording of Checkpoint 1.1
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0097.html
21.JG: Run pwWebSpeak through the guidelines
Status: Done.
http://www.w3.org/WAI/UA/1999/10/uagl-checklist-pww-311
22.JG: Contact Lakespur Roca related to posting for review of
keyboard
support
http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0015.html
Status. Done.
23.JG: Review RS comments on current working draft and update the
issue list
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0063.html
Status. Done, indirectly at ftf.
24.IJ: Contact Microsoft about participation at F2F meeting in
Redmond
Status. Done.
25.IJ: Contact Marja about writing a proposal for what should be
changed
related to checkpoint 2.1 issues
Status. Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0124.html
26.IJ: Propose a checkpoint like the ones for form about table
summary
information (checkpoint 9.9 and 9.10)
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0092.html
2) FTF meeting in December
RS: 7/8 December better for IBM (Austin). Week of the 14th is
very bad (conf room booked, RS in classes). Don't know about
room availability for 9/10.
Who can attend: 9/10: GR, IJ, JG, RS
Unsure: CMN (depends on AU),
KB (question of permission).
HB (issue of access workshop at XML WS).
MRK (may be in Findland).
CMN: Process issues - meetings require 8 weeks from meeting
notice. Exception case ok when WG has consensus about
meeting.
JG: If we don't go to last call next week, we may have to
delay the meeting. If we don't go to last call until
after AC meeting, wouldn't meet to process last call
until mid-January.
CMN: Mid-january would be good for me.
RS: I'll be at a conf first week of Nov. I need to know
as soon as possible.
Action RS: Look into 9/10 December for room availability.
Action IJ: Follow up with Judy on FTF coordination with IBM.
Action JG: Decide if we're ready for last call by next Weds.
3) TODO for last call:
a) Document Chair's/WG's decision to go to last call.
(Done at next week's teleconf).
b) Identify dependencies and track
their responses in a specific list.
Action JG: Before next Weds, send list of people to
contact for last call.
c) Identify issues and track them in the issues list
(annotate the existing issues list mechanism?).
Get sign-off from individuals who raised issues?
Action JG: Include an annotation mechanism in current
issues list mechanism.
d) Charter up to date. Ok.
4) Issue #105: ACCESSKEY implementation issues
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#105
GR: IE implements accesskey somewhat.
JG: Does Opera implement accesskey?
GR: Not in v. 3.6. PWWebspeak latest version may.
CMN: Amaya does not.
GR: One reason I haven't proposed yet to UA is that I'm deciding
whether this is part of G2 (keyboard) or G6 (UI) or G8
(Navigation).
Also, I don't want to lose Tim Lacy's point from face-to-face:
user doesn't care where bindings come from (author or UA). Only
wants to know:
a) What's available
b) How to invoke them
c) What to expect from them.
GR: Discussion in PFWG about handling accesskey. Should PF look
into CSS3 user interface? I don't have much faith in
implementation as defined in CSS3. The onus is on the author
to write platform-specific bindings. It's not the role of the
UAGL to fix broken things.
JG: Author, through accesskey, is adding user interface. Concerned
about author's intent. Also, with current accesskey
specification, no way to notify author of intent.
CMN: I don't agree. You can look at markup and say "This key
provides access to this object."
IJ: You could ask users to provide "title" descriptions.
GR: What is needed (in terms of checkpoints):
1) List of key bindings (default [P1] + current [P1])
2) List changes from default.
3) Cascade order from bindings
a) don't override or allow override of defaults
b) alert user to author-supplied bindings
c) remap conflicting mappings to unused bindings.
4) Consistent behavior on activation. Does accesskey switch
focus alone or do focus + activate? For screen reader users,
I prefer focus alone; decide based on context. May want
a cascade here: focus, focus + activate (with prompt
for configuration).
RS: I'm for cascading of bindings.
KB: About remapping: what's involved in that from a developer's
perspective?
CMN: The user doesn't care where controls are designed. Only
cares about how to operate the UA.
You can use CSS to document what's got an access key.
IJ: How will GR's proposal differ from what's in current G2?
From what I've heard it sounds like there aren't big
issues.
KB: Recall that priority was an issue (due to WCAG).
GR: What's different: Everyone agreed that 2.5 was insufficient:
on/off insufficient since a cascade is required. May need
several checkpoints, may need to put elsewhere.
MK: Turn on/off is like a different mode. When you cascade, you
may lose consistency of mapping.
/* Digression into Guideline 2: whether or not to abstract to
other devices than the keyboard */
CMN: Separating author-supplied bindings is a mistake.
IJ: I agree: 2.5 should be about user final control of
configuration.
HB: When an author changes a binding that the user wants,
this flies in the face of UA design.
CMN: I think the priority of accesskeys in WCAG is orthogonal
to letting the user know how the UA works.
IJ: I think that most of GL2 is not about the keyboard (as MRK
has suggested).
CMN: I agree.
RS: Consensus at ftf was to keep keyboard separate.
IJ: I think it's an editorial issue to ensure that the emphasis
on keyboard access is not lost. I guarantee that the keyboard
emphasis will not be lost.
MK: I think it's important to have "keyboard" in the checkpoints.
It's not clear to me what it means in 2.1 that if you support
the keyboard API, support the keyboard.
IJ: The key word is "all".
JG: I think we need to move this document forward and we may
need to restrict ourselves to keyboard here to finish.
IJ: I think there's little effort to abstract slightly and
it would be worth it.
5) Issue #106: Proposed Abstract revision
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#106
No objections. Editorial.
6) Issue #107: Proposed new checkpoint: 6.7 Support assistive technology
accessibility standards defined for plug-in and virtual machine
systems used by your browser
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#107
RS: Effort has been made to create accessibility environments
(e.g., Java). We need to ensure that standard system functions
are implemented by browsers in this environment.
JG: Is this a technique?
RS: For Java in particular, this is a technique (Java Accessibility
API). Today, browsers aren't implementing the accessibility
features of environments. Like writing a windows browser
without supporting MSAA. Do we extend existing system
conventions Checkpoint?
GR: I support separate checkpoint?
CMN: I'd like to reuse existing one.
IJ: I would say priority 2.
CMN: I say priority 1. The requirement is implicit in other
checkpoints on APIs and conventions. I don't think that
we should higlight the specific case of, say Java Accessibility
API. But recently, this was missed by a major browser.
GR: Need to ensure that developers are aware of virtual machines
in addition to their own software.
RS: I think strongly that this is Priority 1.
JG: Are these standards specific or general?
RS: FCK is a general purpose "screen reader" that talks to
java components that have implemented java access support.
Or it can be components that talk by launching the AT in
the virtual machine. What's missing: ability to load an
AT that will run in the accessible environment. Also,
IE and Netscape don't have the built-in java access API
that would come with the JVM shipped with the browser.
These browsers are not following industry conventions
for the environment in question.
CMN: For any plug-in environment, you must support the accessibility
standards.
RS: Add Java examples.
IJ: Proposed:
Comply with accessibility standards for supported plug-in
and virtual machine environments.
CMN: Sounds a lot like: Comply with accessibility standards. Propose
adding to note that this applies to plugins, virtual machines,
etc.
IJ: Propose adding to "Use operating system and
programming language accessibility resources and conventions,
including for plug-in and virtual machine environments."
RS: How do you handle conflicting standards: system conventions
vs. open standards? Should they have to do both?
GR: We should favor interoperable.
JG: I doubt W3C should promote a particular standard
that it doesn't produce.
Resolved: Add this as a Note to existing checkpoint.
Action Ian: Add this to the spec. For review next week.
Received on Wednesday, 20 October 1999 13:38:06 UTC