Re: Meaning of audio track kind 'descriptions'

On Jun 20, 2011, at 11:19 AM, Silvia Pfeiffer wrote:

> On Mon, Jun 20, 2011 at 6:55 PM, Mark Watson <watsonm@netflix.com> wrote:
>> Is it not the case than when authoring audio descriptions you might want to make decisions to attenuate part of the main audio track to make the descriptions more audible ?
>> 
>> That would be a reason other than legacy technical restrictions for creating "alternative" audio descriptions tracks.
> 
> You can do ducking better when you have separate tracks and the
> ducking can then even be controlled by the user. That's a much better
> experience than a premixed audio track.

Always ? Surely the professionals who created the content are better at creating a new mix which keeps the most important audio elements and ducks the less important ones. Where "important" is even defined as artistic importance ?

> 
> 
>> Silvia: I didn't understand you comment of not seeing a need to distinguish between alternative and additional tracks: surely I need to know this so that I know whether to enable this track in addition to the main track or instead of the main track.
> 
> Who is enabling the audio track? Surely the user is enabling the audio
> track! So, when the user selects the track that has a label of "audio
> with descriptions" (and a kind="alternate"), the browser knows to turn
> off the main audio. I don't see a problem with this.

Two things:
- I'd like the user to be able to enable this track through preferences - ticking the "play descriptions by default" button
- I'd like this track to appear on the same accessibility menu, or under the same accessibility keyboard shortcuts as kind="descriptions" tracks. The user does not care how the descriptions were delivered and doesn't want to see these tracks on different menus etc. based on how they are labeled.

> 
> 
>> It seems like we have use-cases for both alternative and additional audio descriptions. I think the track should be explicitly marked as descriptions in both cases, so we can apply user preferences, include it in the right menu etc.
> 
> 
> Browser settings for user preferences may be a case where we could do
> with an explicit marker on an alternate descriptions track. For
> including it in a menu we don't need it - all we need is a label that
> is explicit enough for the user to choose it, as described above.

No, because the machine can't understand the label. I imagine keyboard shortcuts or other selection mechanisms are useful for people who can't see well.

If it's useful to mark an additive "descriptions" track as such in a machine-readable way then it is also useful to label a alternative "descriptions" track as such. Why does the delivery mechanism affect the utility of the kind marking ?

> 
> 
>> So, how should be distinguish the two cases ? We could have two kind values or use data-*as Silvia suggested (Silvia, could you explain how that works ?).
> 
> A Web developer can add a data-* attribute on any element. It's like
> inventing your own attribute. The Web developer has access to this
> attribute through the JS interface and can do everything with it that
> you can do with attributes. It's very handy for things that are a
> specialized use case.

Sounds like it wouldn't help for in-band tracks, though.

> 
> Cheers,
> Silvia.
>

Received on Monday, 20 June 2011 11:10:04 UTC