- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 31 Aug 2000 16:04:34 -0400
- To: w3c-wai-ua@w3.org
31 August 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Mickey Quenzer
Denis Anson
Harvey Bingham
Dick Brown
Gregory Rosmaita
Eric Hansen
Jim Allan
Tim Lacy
Kitch Barnicle
Charles McCathieNevile
Rich Schwerdtfeger
Absent:
David Poehlman
Next meeting: 7 September
Minutes of previous meeting:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0300.html
Discussion:
1) Implementation report
IJ: I'm starting to gather information for an updated
implementation report.
Agenda:
http://www.w3.org/WAI/UA/2000/08/wai-ua-telecon-20000831.html
1.Proposed editorial changes to UAAG 1.0 (short)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0331.html
Resolved: Adopt unless there are objections on the list.
Action IJ: Adopt in next draft.
GR: I think this is more than editorial.
IJ: Already in introduction (section 1.2, part one).
2.Checkpoint 4.6: question about "rewind"
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0323.html
Proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0332.html
HB: Propose putting my ideas in the Techniques.
Resolved: change the wording to
"start, stop, pause, resume, fast advance, and fast
reverse content that is audio, video, or animations."
GR: Do we have a minimum requirement?
HB: Audio32 is another player that lets you do rewind.
Action IJ:
a) Change checkpoint as resolved.
b) Work to incorporate HB's techniques (e.g., step by song
on a CD).
IJ: Stepping from song-to-song is structured navigation.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0335.html
c) Ensure that technique that involves timing also states that
you have to be able to rewind and fast forward in a
time-independent
manner. Issue of fine motor control. Issue of
device-independence.
3.Issue 297: Style vs. content and background sounds.
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#297
Q: Should we distinguish important from unimportant content? Is
this too hard? Short sounds? Any information used for
presentation?
Q: Should the UA be required to repair bad authoring practices?
MQ: Sometimes you'd like to throw away background music, sometimes
you want background sounds.
DA: I don't know that we can assume that background sounds are
not content. A page could talk about the sounds that play.
GR: Include "onload" configuration techniques.
Load, Don't load this time, don't ask me again.
MQ: I think we should differentiate onload sounds from regular
audio. It's good to be able to turn them off. However, you should
be able to control that audio which cannot be rewound for fast
forwarded.
GR: I want to distinguish playing audio that the user chose to
play v. audio played without express user request.
IJ: Summarizing:
a) I may want to turn all audio off.
b) For audio, video, animation that I choose to play, I want
fine control.
c) For other audio, video, animation that I don't choose to
play, I want to be able to turn off (3.2) while still
being able to play that sound that I can control
(or send to a helper application).
IJ: AG has also talked about short clips (e.g., less than a
sentence) that you don't need to rewind in practice.
IJ: If we have a requirement for the UA to repair bad
authoring (misuse of bgsound and style sheets), we need to
tell people in the document that this is a repair requirement.
TL: You can't trap an onload event. You can have a script
react to an onload event. On Windows, the latest versions of IE
allow the user to set a sound to be played for all loads (one
for starting the load and one for ending the load).
RS: What about this: If the UA provides a mechanism for
allowing the user to control audio or video, then control is
required.
IJ: IE Mac handles background sounds natively (IJ asked Tantek).
IJ: How do we know which audio the author intended the user
not to control? Assumptions today are that "bgsound"
are not meant to be controlled by the user. Why make this
assumption? How do you justify lack of control for bgsound?
I think it's just how implementations work today.
DA: (To developers) Would a browser process background sounds
differently? Is it easier or harder to special case background
sounds?
IJ: I'm moving away from the "onload" model since there is
other content that is played onload (e.g., any OBJECT). Instead,
I like GR's expression of the problem as being "on request from
the user".
KB: If I get an electronic greeting card, so I have to download
a media player just to hear some background beeps.
JG (around the table): Are background sounds different from other
audio?
IJ: Notes that WCAG 1.0 checkpoint 1.1 says
"sounds (played with or without user interaction)"
EH: In light of that, no difference.
DA: From an implementation viewpoint, sound is sound.
MQ: Background sounds and more important audio are different.
GR, HB, DB: I don't see much difference between background
and other audio.
JA: Because authors will do goofy things, it's a simple
repair to say all sound is the same, and the user needs
control of all of them.
TL: I'd agree that a sound is a sound and that programmatically
we treat them the same, whether or not we bring up a player.
EH: Should there be a configurability requirement? For instance,
for some types of audio, just have on/off control.
GR: Note that sounds played on load are synchronized with
anything else played onload.
JG: But not important for unrelated sounds.
IJ: Summarizing:
a) The WG is saying that the UA needs to provide control
over all sounds, even if all users wouldn't have the same
level of control.
b) GR is requesting requirements for element-level control
of rendering audio/video even when there's a global
configuration to supress rendering.
IJ: However, if the UA lets the user control all sounds
(including stop), then the ability to configure all sounds
off on load but play sounds individually is no longer a P1
requirement. It's just a convenience function (P3).
c) Background sounds are misused to convey
information. Hence, providing control even over background
sounds is repair.
JG: What about scripts that play sounds?
IJ: Invoke "recognize" (applicability).
IJ: If the browser lets me turn off sound globally, how
do I get at them individually?
RS: I think that if something is intended for the background,
I think on/off is sufficient. You don't need to rewind or fast
forward it.
EH: Checkpoint 1.1 of WCAG 1.0 calls for a text equivalent of
all non-text elements. I have argued that this should only
be P1 for primary content. You could add further that the
priority drops for "unimportant" content.
IJ: But it's much harder on the UA side to determine what
is important.
EH: So say "in the absence of sufficient rules, then I'll use
these rules of thumb (e.g., based on media type)"
IJ Proposal:
a) P1 requirement to control sound that is not stylistic
(by specification).
b) P2 requirement to control all other sound.
GR: Risk is too high that content will not be available.
EH: Yes, I think that something along that line is appropriate.
IJ: We could say something arbitrary about short sounds,
like "P1 to control any sound that takes less than 3 seconds,
P2 for anything longer."
EH: We can't judge priorities unless we make some assumptions
about a level of authoring compliance to WCAG.
JG: We are largely assuming content that conforms to WCAG.
Action IJ: Write a proposal to the WG about control of audio,
video, animations.
Action GR: Write a proposal explaining what more should be done
in UAAG 1.0 in the way of repair functionality.
Action IJ: Document the assumption that content (unless
explicitly indicated as a repair functionality) is expected
to conform to WCAG.
4.Issue 257: Checkpoint 2.7: Natural language information
http://www.w3.org/WAI/UA/2000/05/ua-minreqs
Resolved: Adopt proposal from Jon with editorial changes:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0123.htmln
5.Issue 257: Checkpoint 2.3: Access to text equivalents
http://www.w3.org/WAI/UA/2000/05/ua-minreqs
EH: The usage of "primary content" is different from the
meaning I proposed. I have used the term "equivalency
target". It looks to me that whether something is primary
or alternative could be ascertained through existing markup
in some cases. I wanted to reserve the term "primary content"
to mean that which the author intended without users with
disabilities.
Resolved: Version in 18 August Guidelines is ok, but
may go back and re-examine use of "primary content".
6.Issue 257: Checkpoint 9.3:
Resolved: Delete checkpoint 9.3.
7.Issue 257: Checkpoint 10.8: Single step access to frequently
used functionalities, list of functions and wording
http://www.w3.org/WAI/UA/2000/05/ua-minreqs
IJ reviews proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0185.html
Resolved: Adopt proposal.
8. IJ: Please add discussion of "primary content" to next agenda.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 31 August 2000 16:04:36 UTC