<silvia> I will be here on irc

<JF> thanks silvia

<scribe> scribe: janina

jf: suggests we go through first batch of comments
... consider how to get them into the wiki doc
... then second batch, and tech reqs
... sec 2.4 clear audio ...

<JF> Sec. 2.4 Clear Audio

<JF> http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0205.html

<JF> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Clear_

<JF> audio

<JF> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq

<JF> 5

jf: seems there was confusion re what clear audio is
... that we're talking about an isolated audio track
... is that correct

sh: my understanding is as used in u.k., believe it's derived
... but that's not the same as the user req
... we need to capture the separation notion

jf: one audio stream, or a derived stream?

sh: could be either

jf: rec is to make it 'separate alternative audio track'

sh: real req is to separate speech in foreground from all background audio

jf: so how much on ua vs content producer

<silvia> question: do we need to insist on having the audio track separate or could it be a track inside a multitrack resource? The latter would be easier to implement.

<silvia> i.e if we have the notion of separate, that should not imply separate resources

<Judy> js: but they can still do that if they are separate tracks

<Judy> sh: [missed]

<JF> (JF sees silvia on IRC)

<Judy> sh: just change the relative volume, it's the normal playback system, the user is in control of that

<Judy> ...if the player always has to play back the standard sound track, you always have to have at least the separation of the 2 channels

<Judy> js: seems to me that you might have a user agent far more capable than just playing one audio track

<Judy> sh: go for the lowest common denominator, that is what you author for

jf: so are we talking ability to see multiple audio tracks -- at the ua

<Judy> js: i think that is very realistic, that's what we're going to see

sh: simplest is just choose a track
... js is correct, much of our other reqs will require multiple audio, or multiple video, or multiple text tracks -- some combo
... so one req is on content provider to make the clear audio available in addition to default audio stream
... second is on the ua to select, either or both

jb: seems we're combining tech and user req discussion

<Judy> judy agrees w/ js' and sh' capture of this -- but we do need to capture it

sh: user need is to be able to listen to either the clear audio stream or the mixed default stream

<Judy> jf: i don't think that will happen

<Judy> js: it has to happen, it's in multiple recc's

<Judy> ec: it will happen in some, and won't be supported in others

<Judy> jf: so we say, support speech as a separate audio track, and leave it at that?

<Judy> js: that would be the reasonable way to achieve it

<Judy> jf: we seem to understand each other, and update the wiki, and move on

<JF> (CA-1) Support speech as a separate, alternative audio track from other sounds.

<JF> (CA-1) Support speech as a separate, isolated audio track from other sounds.

<JF> Agreed!

jf: sec 2.5 content nav by content structure

<silvia> I don't understand the difference between alternative audio track and isolated audio track - hopefully your wiki edits will make these clearer

<Judy> silvia, sean proposed re-naming it, it is not a different thing

<silvia> ok, thanks

<JF> judy notes that minutes are lean

people questioning whether a daisy type audio plus e-text is in scope

<Judy> judy notes that there were no pre-exclusions of scope

<silvia> i would not want to mention concrete formats in the requirements doc other than as an example for describing a requirement

<silvia> requirements need to be independent of concrete tech solutions

<silvia> re daisy and epub

<JF> Eric suggests that the require is that we can associate a document with the media resource that describes the structure of the resource

<JF> EC: we also need to say somehow that it be possible for the user to be able to navigate through the media resource with that infomration

<Judy> judy clarifies for silvia that this was not an explicit discussion of including those formats, but being able to address formats with those types of capabilities

<silvia> good, agreed

<JF> (CN-2) Provide support for a means of describing the structure of a media resource, and the ability to navigate via this structure.

users need to be able to navigate media by its inherent structure, e.g.

can associate a document with the media resource that describes the structure of

the resource

<JF> EC: we also need to say somehow that it be possible for the user to be able to navigate through the media resource with

that infomrationagreement to drop 'inherent'

<JF> (CN-2) Users need to be able to navigate media by its structure (e.g. Using a document that describes the structure of the resource)

<eric_carlson> +1

<JF> Agreed!

+1

<silvia> +1

yes

jb: raises process concern -- we seem to be going item by item again. is there a way to expedite?

<JF> Sec. 2.8 - Judy to track down example for clarification - will coordinate with Sean

<JF> Sec. 2.8 Sign Translation

<JF> http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0269.html

<JF> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Sign_T

<JF> ranslation

<JF> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq

<JF> 9

<JF> Will ask Silvia to make edits to wiki to incorporate the Q & A provided for this section (clarriffication)

<JF> Sec. 2.9 Transcripts

<JF> http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0229.html

<JF> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Transc

<JF> ripts

<JF> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq

<JF> 10

<silvia> there are not enough notes in these minutes for me to know what to edit

<silvia> I can make the edits for the sections that Sean and I reviewed though

<JF> Eric proposes that each group edit the wiki for the sections they responded to/on

<silvia> agreed

<Judy> judy +1 to eric's suggestion. judy & janina will do this thurs or fri

<Judy> judy proposes that all parties capture their changes in the history or discussion page, as appropriate for coordinated wiki work

<silvia> the history page will capture the changes automatically

<silvia> you can put rationale on the discussion page

general group agreement to drop 'keyboard' from user controls and merge two sections as proposed by jb and js

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: janina
Inferring ScribeNick: janina

WARNING: No "Topic:" lines found.

Default Present: John, Janina, +44.154.558.aaaa, Judy, Eric, Sean
Present: John Janina +44.154.558.aaaa Judy Eric Sean

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 07 Jul 2010
Guessing minutes URL: http://www.w3.org/2010/07/07-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report