- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Wed, 9 Jun 2010 18:46:19 -0500
- To: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
From: http://www.w3.org/2010/06/09-html-a11y-minutes.html
- DRAFT -
SV_MEETING_TITLE
09 Jun 2010
Agenda
See also: IRC log http://www.w3.org/2010/06/09-html-a11y-irc
Attendees
Present
+1.650.862.aaaa, Janina, Michael_Cooper, John_Foliot, AllanJ,
+1.408.307.aabb, +44.154.558.aacc, Eric_Carlson, Sean_Hayes,
+61.3.986.4.aadd, Kenny_Johar, Judy
Regrets
mhakkinen, gfreed
Chair
SV_MEETING_CHAIR
Scribe
allanj
Contents
* Topics
1. Action Items www.w3.org/WAI/PF/HTML/track/products/2
2. Review of Straw Poll
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results
3. Audio Description
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq3
* Summary of Action Items
<JF> slim pickin's here. I anyone dialed in?
<scribe> scribe: allanj
Action Items www.w3.org/WAI/PF/HTML/track/products/2
<MichaelC> close action-35
<trackbot> ACTION-35 Write cues requirements closed
Review of Straw Poll
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results
Audio Description
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq3
question: (AD-4) is a requirement to synchronize audio/video resources from
potentially different servers. This is potentially much more difficult than
synchronizing text to a media resource. The current work on <track> is not
trying to solve this, so if this is important then it should be stated more
clearly.
js: use case. would need to buffer them before presenting.
jf: coming from different servers
... at university, flash player wants all resources on same server
... is this easy or hard?
sh: requirement is about quality of voice, description should be able to be
human speech.
... difficult to provide from different servers.
... should clarify, that this is a user requirement.
jf: should we start collecting technical requirements?
... yes (personally)
sh: should have separate doc or section about technical requirements
ec: difficult to synchro at playback time. need hooks at very low level.
jf: can you not have media, audio and text files in a same wrapper
sh: constraint on the platform, desktop vs mobile
... use case is still valid
js: sounds like a SHOULD not a MUST
jf: perhaps all should be prefaced by platform, player
js: conditional, media,
jf: platform support
js: if provide described video then do this. if not it doesn't apply
sh: html5 has language like this regarding CSS
... spec cannot require a UA how it implements CSS
... we are in similar situation
... can say, this a description for that, expect certain UA behavior, but
can't require it
... can not say you have to do xyz. may be able to set some semantic
requirement.
... remember this is a content spec, not a UA spec
jf: external files are more difficult, not expecting separate servers.
js: just drop it to a SHOULD level. don't prohibit it
jf: phillip seeking clarification.
js: SHOULD not required so no clarification needed.
QUESTION: (AD-5) and (AD-6) assumes that several audio tracks can play in
parallel at all. This is unlikely to be true in the near future.
js: this is possible now depending on device. have them on the mobile device
now.
jf: devices have ability to independently adjust volume.
sh: content vs device or UA
... it depends on device. expected behavior is that each channel have
separate volume.
jf: if more than one audio track,
sh: but player may not be able to control independently if no API
jf: device should allow this control
sh: expected behavior based on existence of api is foofoo
... this is what author expects the UA to do.
js: if UA supports multiple audio through api, them MUST be able to control
independent audio
... then play all at same volume.
sh: yes, and the UA would die. this is content. MUST for syntax of what
author writes. then, foo is the expected behavior for the UA
jf: since html5 puts the media player native to the UA, then the UA is the
player, and html5 must write to it
... where is proper place for the language.
sh: would be great if html5 says UA must comply with UAAG20
js: this is different from where I am coming from. everything would be a
SHOULD.
sh: html5 spec should specify expected behavior.
js: ok with this for now.
jf: this document may be a reference for more than one working groups
js: use CSS example from spec, and model media language around it
QUESTION: (AD-7) seems like a quality of implementation issue, I would
remove it.
js: make it a SHOULD. it's nice to have it.
ec: what does smooth changes in volume mean
js: infinite volume control
ec: volume is a floating point number, it provides what is asked.
sh: right. this is still a user requirement. just because it is done, does
not mean we discard it
js; floating by 10, 20, 30..., want 1,2,3...
sh: smooth is with out perceptible artifacts, technically, this is a UA
implementation.
jf: want a ramp not steps. how to state so it is clear to engineers.
discussion of volume controls native UA or scripted
ec: must ahve same requirements on apis, author who writes a script, must be
able to write to api
js: need to move this to 'controls' section not in authoring
sh: all interdependent. spec for controls, api for changing, and audio
representation.
jf: are we asking for stereo balance/fade controls
... is it in this requirement, or in the controls section.
sh: important for listening to 2+ audio streams. standard TS is one premixed
stream,
... audio description is outside premixed stream, and must be intelligible
jf: must panning fading also smooth
js: this is a UA issue not authoring
... UA must provide the controls to allow user to adjust volume, balance,
fading, audio tracks
jf: thinks some audio description requirements should be in controls
js: need to change 'author' to UA and requirements are ok
jf: if author writes a custom control, then it is no longer a UA issue.
ec: author writes control, says ignore native control
sh: author should be able to write declarative statements to the api
... spec describes how the control behaves, not what or how it controls in
the background
... some of these things are in multiple groups. no good way to group them
because the groups are too granular
jf: in terms of controls, they must support the controls as outlined in
section X
sh: just want to make sure all the controls maintained in the document
somewhere
QUESTION: (AD-9) Is too vague, isn't it enough that the audio codec works
well for voice rather than it was specifically designed for it? If not, is
it Speex we want to require?
ec: is the requirement that the player must support more than one codec.
... this says nothing about the quality of the output
... should support a codec that supports human voice.
... webm only supports one codec. putting requirement for more codecs will
not change it
jf: agree with eric.
sh: audio description must be sufficiently legible
ec: address output of audio codec for human voice, not specific codecs
QUESTION: (AD-11) Is the requirement the same as (AD-3), or is it a
requirement on UA to be able to select the audio output device? This seems
to be something usually controlled by the OS, not the UA.
sh: watching video with wife, one wants description the other not. its about
shared audio.
... this is not the same as AD3 multiple description tracks.
js: multiple description tracks is different languages
jf: this is usually controlled by the OS not the UA
js: if multiple output devices, there should be a way to control these
QUESTION: (AD-12) There is no concept of "program" or "channel" in the spec,
clarify or remove this requirement.
sh: if I change source on media element, want descriptions to change
jf: change 'channel' to 'media asset
ec: want a discernible pause when changing assets
sh: don't want to confuse user
... if in the middle of description stream, and switch to a different media,
want the user to know that things changed
jf: in a play list, things fade in and out as one starts and another stops
js: if scene changes but the description doesn't,
ec: description must stay synchronized with the parent media
sh: right. if a smooth break in scenes, but descriptions run into each
other, it confuses the reader. like changing channel on radio quickly to
make nonsense sentence
ec: need a distinct break when changing media
sh: right. in TV there is half second break on the SAP channel, but not in
the main audio.
ec: this is good and makes sense. need to reflect it in the requirement.
jf: need some discernible audio gap in the description track when moving
between media
... how to move forward.
... want to condense comments to help us move forward
jb: not just distill. need to capture the questions, list them, to get folks
to address them.
... half meeting has been problem identification. this is good.
ec: there are a number of questions in the middle of the comments.
<scribe> ACTION: JF to synthesize comments and list questions [recorded in
http://www.w3.org/2010/06/09-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-48 - Synthesize comments and list questions [on
John Foliot - due 2010-06-16].
<MichaelC> ACTION: foliot to distill results of media requirements survey
[recorded in http://www.w3.org/2010/06/09-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-49 - Distill results of media requirements survey
[on John Foliot - due 2010-06-16].
Summary of Action Items
[NEW] ACTION: foliot to distill results of media requirements survey
[recorded in http://www.w3.org/2010/06/09-html-a11y-minutes.html#action02]
[NEW] ACTION: JF to synthesize comments and list questions [recorded in
http://www.w3.org/2010/06/09-html-a11y-minutes.html#action01]
[End of minutes]
Received on Wednesday, 9 June 2010 23:41:32 UTC