<trackbot> Date: 04 May 2011

<JF> Meeting: HTML-A11Y telecon

<JF> agenda: this

<JF> is mikesmith really on this call?

<JF> meeting: WAI_PFWG(A11y)

<MichaelC_SJO> trackbot, start telecon

<trackbot> Meeting: HTML Accessibility Task Force Teleconference

<trackbot> Date: 04 May 2011

<JF> Meeting: HTML-A11Y telecon

<JF> Chair: John_Foliot

<JF> agenda: this

<JF> thank you michael

<JF> now we have a double agenda

<JF> scribe: Sean

<scribe> scribe: Sean

<JF> thanks michael

Identify Scribe

Next Steps on Multitrack: Listing Kinds/Types Actions Review

JF: can someone bring us up to speed

MW: Wiki page updated

the rmaining issue is about the track labelling

some discussion on email, dived down into distinctions between add-on and alternatives

no conclusion

JF there was discussion about making the list in a 3rd party location

any more thoughts on that?

<mark> http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds

SP: we shouldnt be overdoing it, its a bit of a detail

we should discuss the list

but the addition/replacement issue is somewhat orthogonal

and should probably not be solved in kind

should stay in the realm of what content the track contains

for now

MW: Should go through list on the wiki

JF: We are coming to a deadline, so we need to add something into the draft

can we generate a list to go into the spec

SP: Some already in (5 main ones)

main issue is additional types

and defining what they mean

we need to follow implementaiton

as we gain experience

the ocation of the list not a big issue

MW: The wiki contains definitions
... when we work out an independant place, we can move them

JF: can we walk through them

MW: posted the link,

BL: Q. get kind function: suggests some kinds, some of which are text oriented, but no value of GetKind matches

MW: we are talking abot getKind on AV tracks, e.g. for burned in captions

text tracks are out of scope here

group from OGG for effects in different tracks

JF: would speech map to clear audio

SP: 2 ways to look at it, if its pure voice then yes

but Dave Singer says its the same as the main track but with different mix

both are viable approaches

dont know which clear audio is

<JF> SH: my understaning of clear audio as used in UK/BBC there it is a differently mixed but replacemnt track

<JF> no requirement for client side equipment to do the mixing

<JF> could be a pure speech track, and may in fact be derived from a 5.1 channel setup

<JF> as a seperately signalled audio stream

<JF> EC: That is my understaning as well

in whch case alternate could be adequate

MW label can tell a human user which is which

issue is whether there multiple alternates and the machine can tell which track is which for user preferences

and then the label needs to be machine readable

JF: probably seems we need something which maps to clear audio

MW: The OGG expectation is that the client will mix them

Pure alternates is simpler, especially for audio

because mixing requires that the tracks are actually authored for that

JF: do we see browsers providing that kind of mixing

EC: We do it to the extent that the platform allows it

MW: I meant more about the track preparation

if the difference is just relative volume

its only going to work if the audio signals are precisely aligned

the content needs to be prepared with that in mind

if the intention is separate presentation, the tolerance is much less

EC: agree

its unlikely that audio will be prepared in that way

synced at the sample level, as it isnt going to always play well

JF: the 3 kinds can be dropped

MW: supplementary kind

from 3gpp

which indicates whther the audio or video is the most important, and is a hiint as to which is expendable

SP: That doesnt fit the kind attribute

EC: agree, its a characteristic; its different to kind

MW: its not alternate, video=main audio=supplementary

or for a concert the reverse

I agree the concept is not well defined and specific to adaptive streaming

SP: Some things need to be left to the website devloper

and the tools are there

to achieve this

custom controls can do this

and for adaptive streaming can look at the statistics

handle in JS

MW: Can agree this is not a kind, but for a different reason
... Will update Wiki

I see it more that is dealt with the media player, that uses these labels from the manifest and doesnt need to be handled by JS

but the outcome is the same

Next is commentary

intended for director commentary

JF: alternative doesnt apply here, this is a +?

MW: the same issues apply here, you dont typically hear the main dialogue etc

its an either or

EC: the question is is it likely that there will ever be a track that has commentary that also needs an another type of kind too

JF: if the commentary is a separate track, it would need to have a text track equivalent

goes back to production

if its an either or, then there would be two transcripts one for each

if its a mixin audio, then we would need to mix texts

dont know how to handle that

MW: My understanding its completely separate

synced to the vide

there may be a switch track

so labelling the captions is an issue

JF: so could render two text files concurrently

MW: if the commentary is alternate, then the two captions should be alternates

SP: it would usually be an alternative

pre-mixed

in which case it would have its own subtitle track

and select that as an alternative

so marking as alternative is sufficent

MW: the issue is again whether you want to have user choice or UA selection

JF: if its kept generic and use the label, gives us room to explore

form ease of authoring for after market stuff it would be easier

alternative would be the powerful kind, and use label to slice and dice

MW: today we expose this label for our UI code to find this

in 3gpp and DASH there is no label for this so the UI can generate the labe

we should respnd that we need user readable labels

SP: kinds and the lable (internationalised) would say this is a commentary

prefer to keep the number of kinds small as possible

there is no way to put labels currently in DASH

just that its an alternate

2nd point - pros and cons, simple to have alternative

but the other option allows the scripts can do more with them

to apply preferences for example

JF: A machine readale type would be usable

EC: but that means people cant make up their own labels

MW: the issue is what level of granularity do we want for Machine readable

SP: alternate and accessibility are about it

no further kinds required

MW: that assumes a specific UI

to generate labels automatically for example

SP; what the browser interprets may be different

MW: if browser handles it, then it needs to handle i18n

SP: we need to look to implementaiton

MW: for what we do, the API is similar to the one being defined here

we expose the different kinds to the UI designer

SP: good to have experience in the design

JF: so need to continue the discussion, but lets looka the rest

MW: next 2 are captions and subtitles

in this context refer to burned in

MW: do we need to distinguish here

JF: the difference is somewhat academic, what counts is what goes to the screen

SP: we could have a captions kind and use label to distinguish

JF: could work
... machine readable label

BL: on subtitle vs captions, there are FCC regulations that require captions but not subtitles

EC: that argues for them beign separate

MW: we could have a structure to kind

e.g getSubkind

or have the value embedded in the valu

some value in aligning with text tracks

EC: agree, doesnt make sense to define a hierachy.

lets keep it simple till we know we need it

MW: agree

avoids topolgy discussions

not enough types really for a hierarchy

so we will have both top level types

JF: need to file a bug

MW: will file a bug for all of the list together

next one is video mosaic

EC: seems unnecessary

not very common in the wild

JF: agree

not really accessible

BL: not an access feature, but is a common UI

could be constructed using separate elements

but that doesnt work too well in low bandwidth

MW: so the idea is its a singel video with all the videos in it

BL: yes thats how its authored

built from low bandwidth stream built automatically

EC: seems a special case that needs custom layout

for now I think its better off not to have an explicit way to mark it, and require custom code

MW: agree

SP: should be done in layout, as I understand it

as they are in reality separate tracks

BL: agree

MW: clear audio.

JF: have the impression is that directors commentary and clear audio are both differently mixed audio tracks

MW: yes

JF: so if we have a clear audio kind, then we need a commentary kind

but I'm hearing a disinterest in that

SP: Clear is an accessibility issue

so we need more automatic switching for preferences

but dont see need for that for commentary

EC: agree, furthermore they are actually orthogonal

could have a clear audio commentary

JF: it really comes down to how produced

MW: the decision criteria, is does the JS need to know in machine readable form

if you want UI elements tailored to these things

sp preferences is not relevant for commentary, but a UI design is

seems we keep finding examples where we need to label with more than one kind

could be a structure under this

lots of these are too specific fo a generic matching algorithm

and maybe we do need multiple kinds

SP: can we explore that later

MW: yes as a first pass we should decide on what are the kinds

JF: Dave Singer has suggested 5 more, should we add these now?

are these in fact being produced

MW: its hard to introduce kinds if we dont have good definitions

EC: another example of where we dont have enough experience yet

JF: the clear examples now a re captions and clear audio

MW and subtitles

and commentary still under discussion

SP: dont want commentary as a kind

suffucient to use alternate

SP: have added a rationale to the wiki page

kind should define a track so that the UA or developer can make a decision whther to expose it as an addition or replacement to the main content

and amenable as a preferences decision

access and i18n are the main reasons

MW: agree the user preferences argument doesn apply to commentary

but dont agree thats the only reason for defineing a kind

custom UI is also a reason

SP: can use label

MW: but if I dont have a label, JS cant tell the difference

if I have label, the constraint is they are human readable

EC: commentary is so specialsed

only applies to some specific movie forms

JF: we have 3 clear winners, plus some discussion

maybe we should file a bug now on those 3

reopen or a new bug?

probably easier to file a new one

needs some investigation

but the takeaway today is we have 3 definite new kinds

continue to discuss on the list and wiki

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: Sean
Inferring ScribeNick: Sean
Found Scribe: Sean
Inferring ScribeNick: Sean
Default Present: John_Foliot, +1.408.540.aaaa, +1.510.367.aabb, +44.154.558.aacc, +61.2.801.2.aadd, silvia, mark, Sean, +1.510.367.aaee, Eric
Present: John_Foliot +1.408.540.aaaa +1.510.367.aabb +44.154.558.aacc +61.2.801.2.aadd silvia mark Sean +1.510.367.aaee Eric
Found Date: 04 May 2011
Guessing minutes URL: http://www.w3.org/2011/05/04-html-a11y-minutes.html
People with action items: 

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