- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 22 Feb 2001 16:01:47 -0500
- To: w3c-wai-ua@w3.org
22 February 2001 UA Guidelines Teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0241
Minutes of previous meeting 15 February 2001:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0227
Next meeting: 1-2 March face-to-face
http://www.w3.org/WAI/UA/2001/03/ua-meeting
Present:
Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham,
David Poehlman, Tim Lacy, Eric Hansen, Jim Allan,
Gregory Rosmaita, Mickey Quenzer, Rich Schwerdtfeger
Absent:
Charles McCathieNevile, Kitch Barnicle, Denis Anson
-------------
Announcements
-------------
- Glossary meeting Tuesday, 27 March 1-5pm in Cambridge
[More information to be sent]
- Bridge information for next week's meeting will
be available from meeting page:
http://www.w3.org/WAI/UA/2001/03/ua-meeting
- Meeting agenda:
http://www.w3.org/WAI/UA/2001/03/ua-agenda
JG: Note that we will have some demos during the meeting.
- Any UA meetings at CSUN?
JG: No.
Who's going to CSUN (21 March - 25 March)?
JG, JA, HB, RS
RS: On Friday morning 23 March at 9:20, I'm doing a presentation on
the "universal access gateway"; accessibility on the
server. Information is distributed to clients. I'll see if I can
have this taped.
Action RS: Send pointer to information about universal access
gateway to the WG.
TL: I think we have some Microsoft folks going to CSUN, but I
won't be attending.
IJ, GR: Not attending.
----------
Discussion
----------
Coordination of joint meetings with DOM and CSS
CSS: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0237
JG: What about dev-independent support for :hover?
IJ: This is style, so probably not pertinent.
GR: Are behaviors still being discussed?
IJ: I think there are new proposals in the works.
IJ: I expect to talk to the WG on Tuesday morning. Others
are welcome to join me.
DOM: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0213
RS: I put in my requirements for DOM 3 to the PF WG.
- Add style sheets (not necessarily on the client side).
- Need an API to the computed value of a property (without
implementing the cascade).
IJ: Not sure this would work in some @media cases
(since the browser may not do speech, for example).
IJ: Additional idea from Aaron Leventhal: add a DOM module
to account for what MSAA does and the DOM does not.
RS: We talked about this PF. We were trying to extend the DOM up to
the application layer. You put an overlay over the DOM to get DOM
+ application specific information. It's a lot of work to get this
happen (e.g., a subgroup of the DOM WG). One thing that the JAVA
accessibility API does (and we're looking for in MSAA), is to
create an indexable character interface to documents (something
like an offscreen model interface).
------
Issues
------
1. 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
5. Issue 394: Checkpoint 2.1: Vague about what cannot be
provided through a source view
Proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0249
IJ Reviews proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0249
HB: Why "optional" and not "alternative"?
IJ: Optional content is a larger class (including titles,
alternatives, etc.)
JG: My concern is that checkpoint c is P2 in this proposal.
Why P2 here?
IJ: Strictly speaking, checkpoints a and b are P1 and
provide sufficient access. Checkpoint c did not qualify
for P1 strictly speaking.
EH: When we were considering the priority of 2.3, in my mind,
it was P1 because the old 2.1 was broken. The source
view was not a P1 requirement at that time. In this proposal,
I think the need for P1 is lessened.
IJ: Another piece of the reasoning behind why (c) is P2:
"content meant for users" is not always clear, and therefore
it was difficult to push this as a P1 checkpoint when this
intention is not clearly discernable in the format.
GR: "Required optional content" is a little weird.
IJ: Good point!
Action IJ: Find clearer wording.
GR: I propose changing "optional content" to "conditional content".
I think that conditional doesn't presume that one form of
content is preferred over another.
IJ: I don't think "optional" suggests that optional content
is lower class.
JG: Does the proposal overall seem to capture what the WG
was trying to capture with the original 2.1 and 2.3?
GR: I think that this proposal improves the document.
DP: Me too.
TL: Me too.
JA: Me too.
MQ: Me too. But unsure about the definition of "optional content".
Action IJ: Put back rationale about why user control of optional
content is required (to allow users to find useful equivalents).
JG: Who wants checkpoint (c) to be a P1 checkpoint? Since few people
will be able to use a source view to get at optional content, I think
it should be P1.
P1: MQ (I don't like to have to depend on the user's access to
source code), GR, JG (I don't think most users will be
able to do this).
P2: JA, DP (I don't think we'll gain anything by raising to P1),
RS, TL, HB (You have access to the source view, the fallback).
IJ: I don't feel strongly about limiting (c) to P2. I know there
are arguments on both sides.
EH: I feel similarly. This may not be strictly P1, but it makes
it hard on the user. But if you abuse "P1" a lot, it ruins
credibility. So I think P2, but I don't feel strongly about it;
I probably wouldn't object to P1.
JG: I think that making (c) a P2 would be a big change to the
document. E.g., low-vision users having to access "alt"
through a source view.
GR: How will someone with a severe cognitive disability use a source
view to access unrendered optional content?
IJ: Note that (a) gives "alt" text when images are turned off
(in the case of HTML). Don't bind 3.7 to Guideline 2 since
3.7 is not specific to HTML.
EH: I think that (c) is a repair function, in the sense that either
the original spec wasn't adequate or because the user agent
can't understand that specification.
Resolved:
- Accept the proposal with (c) as a P1.
- Add an issue to the issues list about the priority of (c)
(to lower to P2).
2. Issue 430: What classes of animations are covered by our
G4 animation requirements?
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#430
IJ: Status of question of what classes of animations should
be covered by our requirements to control animations.
Refer to question on the list:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0250
3. Issue 443: Checkpoint 1.4: Device independent access to pointer
(mouse) specific events.
IJ Proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0243
JG Additional Proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0248
JA: I agree with IJ's comments on this as a repair issue.
I think that checkpoint (c) should be P3. You can emulate
all kinds of things and you're not guaranteed of a result.
And from what I've heard from Rich and others, I think this
would be hard to implement.
/* JA leaves the call */
GR: I think that the ultimate call needs to rest with the user, not
the user agent; the user should be able to turn off the
emulation feature or use it.
JG: Everyone I've asked about this repair says "P1 since this is
prevalent on the Web - authors are doing the wrong thing."
What is it reasonable for the UA to do that would potentially
benefit the average keyboard user? So I proposed a fourth
checkpoint.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0248
Checkpoint D: Provide keyboard activation of the following
pointer based scripting events for elements with explicit event
handlers: onClick, onDblClick, onMouseOver, onMouseOut, onMouseUp
and onMouseDown [Priority 1].
IJ: This is specific to the DOM and HTML.
JG: I'd rather have the necesssary repair be as narrow as possible.
People tell me that this is a major problem and the UA needs
to do something.
IJ: Is this repair really useful for users?
GR: That's up to the user to decide.
IJ: Why does mousekeys not suffice?
GR: You need snap-to-focus functionality.
JG: Moving the mouse automatically breaks GUI design rules.
But unless you can get to the focus with mouse keys,
I don't think it would meet the requirement.
IJ: Note the different levels of requirements:
a) Manual emulation (fishing around)
b) Automatic emulation (trigger onmouseover when onfocus occurs).
No resolution.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 22 February 2001 16:01:55 UTC