W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2010

Re: [media] handling multitrack audio / video

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 3 Dec 2010 08:28:20 +1100
Message-ID: <AANLkTinPiDg3Ymrmg5irAuEE+O255ftHdpyHk4cAtL6i@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Geoff Freed <geoff_freed@wgbh.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>
On Fri, Dec 3, 2010 at 2:41 AM, Eric Carlson <eric.carlson@apple.com> wrote:
> On Dec 2, 2010, at 6:31 AM, Silvia Pfeiffer wrote:
> For #3 there is not much to do actually - just having a means to
> switch between resources would be sufficient. That means could be a
> button underneath the video or a second tab with the video and lets
> the user change between the main video and it's auditory-only
> counterpart. I wonder if we even need special accessibility features
> for this.
> The idea we have long talked about to use media queries on a <source>
> element to label the accessibility features of its resource could be very
> useful here. It would allow an author to include videos with and without
> open audio descriptions in the markup:
>    <video controls>
>        <source src="trailer_with_open_captions.m4v"
> media="accessibility(audiodescription:yes)" >
>        <source src="trailer.m4v">
>    </video>
> and the user agent will automatically choose the captioned file if
> the user's preferences say they want them.
> eric

So, the other way of doing this is through introducing a @kind
attribute like we have it on <track>. We could have

 <video controls>
       <source src="trailer_with_open_captions.m4v" kind="descriptions" >
       <source src="trailer.m4v">

That would similarly signify what type of tracks are available in
content. It would also probably mean to extend the @kind attribute to
allowing more than one value, since there could be multiple tracks in

I am, however, wondering how either of these solutions will interact
with the resource selection algorithm. It seems to me that the
algorithm currently states that when the first resource is found that
the browser is able to decode, it will stop and not search for more.
So, even if we say that a user would prefer to listen to a video with
audio descriptions over a video without audio descriptions, we cannot
make the lack of the @kind attribute or the @media attribute one that
completely dismisses a <source> element. If, for example in the above
example the <source> elements are ordered the other way round like

<video controls>
      <source src="trailer.m4v">
     <source src="trailer_with_open_captions.m4v"
media="accessibility(audiodescription:yes)" >

then the browser would always pick the one without the audio
description first, since it cannot assume that one with audio
description will eventually come.

Do you have a solution for this case?

Received on Thursday, 2 December 2010 21:29:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:49 UTC