- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 29 Jun 2000 15:49:02 -0400
- To: w3c-wai-ua@w3.org
29 June 2000 UA Guidelines Teleconference
Present:
Ian Jacobs (Chair/Scribe)
Gregory Rosmaita
Dick Brown
Tim Lacy
Mickey Quenzer
David Poehlman
Eric Hansen
Regrets:
Jon Gunderson
Kitch Barnicle
Eric Hansen
Mark Novak
Jim Allan
Absent:
Harvey Bingham
Charles McCathieNevile
Next meeting: 6 July.
Regrets: EH (maybe).
Agenda [1]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0522.html
Summary of resolutions:
1) For checkpoints in Guideline 3, it would seem that
"turn on/off" means at least "allow the user to configure the
user agent so that content type X is not rendered on loading."
For example, this may suffice for blinking content as an
accessibility solution. More may be required for other content
types, but we didn't get far in the discussion.
Summary of new actions:
1) Ian will produce a new draft that folds minimal requirements
into the checkpoints. Should be ready about 7 July.
2) Ian will pick up GR's action item to send out a request
for information on speech synthesizer mins/maxes for
various articulation capabilities (as we did for speech
rate).
1) Eric Hansen's proposal to make checkpoints express
minimal requirements directly.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0508.html
/* IJ explains EH's proposal, since EH not yet on the call */
GR: I think there's a middle ground. There are checkpoints where
you can roll the min req into the checkpoint and make it clear.
But what if people think we are being too specific.
IJ: Resolves a number of issues for me:
a) Where to put the min reqs? A: They are the checkpoitns.
b) What is the normative status of the Notes? A: Checkpoints
normative, notes informative.
DP: Checkpoints shouldn't be to long.
IJ: I propose to do a draft with min reqs built-in.
Action IJ: Put out a new draft in a week.
2) Single key (10.5) from Kitch
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0433.html
DP: I have an overall question: how specific do we get?
GR: Single-key should not be limited to "do this thing". They
should also be able to "put me in this mode". So, for example,
arrows always do conceptually the same thing. The same range of
ten can be used for different modes.
TL: This is a topic that we've discussed at great length
in MS. IE is restricted to single key anyway. Within the
browser window, the concept of up/down and left/right doesn't
really exist.
TL: Three things would have to happen:
a) You'd have to expose what kind of container you're in.
b) You'd have to expose what keystrokes are available.
c) You'd have to provide a programming language to allow
and end user to map strokes to events on the fly.
MQ: I'm concerned that we may leave some functionalities out,
though I like the list.
IJ: This is hard one since it involves user preferences. Also,
two sets of values to choose from: functionalities and input
resources (e.g., number of keys). I have fears about having a
concrete list of functionalities, although I agree that we may
have to end up with that as the minimal requirement.
No resolution.
/* MQ Leaves */
3) PR#287: Proposed clarification to checkpoints 3.3, 3.5, 3.6
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#287
In particular, this proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0496.html
This satisfied my action from last week:
Action IJ: Propose a new 4.6 with deleted 3.3, 3.5, 3.6.
/* We did not discuss the proposal, but turned immediately to the
question of what "turn on/off" means */
Discussion of turning on and off:
a) Does this mean globally, by configuration?
b) Does this mean on a piece-by-piece basis once rendered?
Resolved:
i) Turn on/off means at least "don't render globally, allow
configuration of this setting." It's an "on load"-level
configuration.
ii) Background audio means "on-load" audio.
TL: The second piece is tricky: it assumes that items are
selectable. It also assumes that you would know enough
about the object to decide whether to turn it on (off).
From a technical standpoint, if you can navigate to it,
you should be able to activate it. So technically possible,
in my opinion. The problem is activating 100 wave files before
getting the one you want.
IJ: Breakdown of requirements:
a) Never on (resolved above).
GR: But you may want one media type (e.g., real audio)
and not another (e.g,. wave).
IJ: We haven't had mime-type level selection as a
requirement.
GR: User agent could prompt user to load.
b) Once on, allow me to turn off.
c) Turn off, then on again.
d) Global or individual level?
/* Eric Hansen joins from a New Jersey rest stop! */
EH: Cross these axes with audio/video/tactile tracks...
IJ: For example, I could see that blinking should be P1 to
turn off statically. But audio and video are different.
a) background images:
EH: What is a "background image"?
IJ: Other content is rendered "in front of it", towards the
user. This applies to multi-layered presentations as well.
EH: Is it just the image in the "way back"? Every layer needs
to be controlled, except the one in the front.
GR: If the UA supports multi-layering, that becomes a
requirement.
EH: So every supported layer needs control. The user needs
to be able to determine what is distracting. So users
need to be able to turn off about every layer. An
interesting technique would be to present layers adjacent,
as thumbnails.
TL: I can think of cases, with style sheets, to determine
what the background image is. If you define the simple case
where the lowest z-order is the background, you have to
check every time. I think that if you say that the UA has
to disable the background, that should cover the most
important cases.
DP: Applicability can be invoked here.
TL: If markup says "this is the background", that's easy.
IJ: What do you render in place of a background image?
GR: You get whatever would have been rendered without the
background image...
IJ: Do we say that for any layer below the topmost layer,
you need to render the default background in its place.
b) moving visual track (video, animations):
c) blinking content:
- global setting, don't blink, render static
content instead. P1
d) scripts, redirects.
e) images
[ITEMS BELOW NOT DISCUSSED]
4) Min / Max requirements for speech synthesis rates. Refer to
Gregory's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0482.html
5) Multimedia definitions.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0517.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0520.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0503.html
6) Checkpoint 7.5: Proposed search minreq: case-sensitive forward.
7) Checkpoints 6.1, 8.1, 2.7, 8.2, and 8.3
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
8) Other minimal requirements part of issue PR#257 (No proposals)
a) "Easy access": 10.8, 2.3
b) Checkpoint 10.4: Input configuration
c) Checkpoints 4.13 and 4.14: selection and focus highlight
d) Checkpoint 9.3: Configuration of notification.
Open Action Items:
1) IJ: Draft a preliminary executive summary/mini-FAQ for developers.
(No deadline.)
2) GR: Look into which checkpoints would benefit from audio examples
in the techniques document.
3) GR: Pursue speech synth ranges for other properties than
speech rate.
GR: Pending. Trapped on my machine.
Actio IJ: Send out message to various people asking for
range information.
4) GR: Re-examine the orientation checkpoints and
see whether they can be clarified to account for control
of rendering of audio (and possibly other content) on load.
Dropped Action Items:
1) CMN: Propose a technique that explains how serialization plus
navigation would suffice for Checkpoint 8.1.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 29 June 2000 15:49:07 UTC