Re: Meaning of audio track kind 'descriptions'

On Mon, Jun 20, 2011 at 6:55 PM, Mark Watson <> 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.

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

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

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


Received on Monday, 20 June 2011 09:20:30 UTC