- 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