W3C home > Mailing lists > Public > public-html-a11y@w3.org > June 2010

Minutes- HTML A11y TF [media sub-group] teleconference: June 9, 2010

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>
Message-ID: <016801cb082d$f5975fc0$e0c61f40$@tsbvi.edu>
From: http://www.w3.org/2010/06/09-html-a11y-minutes.html
09 Jun 2010


See also: IRC log http://www.w3.org/2010/06/09-html-a11y-irc

    +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
    mhakkinen, gfreed


    * Topics
         1. Action Items www.w3.org/WAI/PF/HTML/track/products/2
         2. Review of Straw Poll
         3. Audio Description
    * 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
Audio Description

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

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
... 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

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

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

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

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
... 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

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

<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
[End of minutes]
Received on Wednesday, 9 June 2010 23:41:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:40 UTC