[media] Moving forward on the Multitrack Media API (issue-152)

Dear fellow accessibility enthusiasts,

Over the last few days I have put a lot of effort into analysing the
discussion that we had about the multitrack media API.

This work goes towards creating a solution for:
* video descriptions that are provided as audio files,
* sign language video,
* dubbed audio tracks
* and similar alternative a/v content that we want to deliver together
with a main video resource.

We actually have issue 152 open for this and the chairs have solicited
a proposal by 21st February
(http://lists.w3.org/Archives/Public/public-html/2011Jan/0198.html).

So, I would like us to discuss the available means of solution a bit
further and if at all possible come to an agreement on the most
optimal solution to propose to add to the spec. Then we can send that
in as a change proposal before the 21st February. It's a tight
deadline, but we have discussed this before (thread starts at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Oct/0520.html).

I have put the different approaches that were discussed together in a
wiki page, see http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API
.

You will notice that this is not a simple decision to make and that
basically all approaches have advantages and disadvantages. Microsoft
(through Frank Olivier) have previously stated support for solution
(2), while Opera (through Philip) have stated support for solution
(6).

I personally believe that solution (7) seems the most readable while
at the same time not overly complicating the JavaScript API. It
retains the use of the @kind, @label and @srclang attributes on the
<track> element, while at the same time making full use of the
capabilities of the audio and video elements. It would require
additional visual indication on the "dependent" audio and video
elements that they are sub-controlled by the main resource. For
example, the @controls attribute must be ineffective on these
dependent elements. Also I think we should introduce specific styling
for them when they are by default inactive. They will be by default
inactive unless the user has a setting to make such tracks by default
active (a HoH user may have sign language on by default and a VI user
may have audio descriptions on by default).

In addition to solution (7), I also would like to see solution (1)
supported. However, solution (1) goes hand in hand with a solution on
HTTP adaptive streaming and the specification of a manifest file
format is still a while off - being worked on in other circles. So, I
think the two can go in parallel.

Please don't hesitate to make changes to the wiki page where I have
made mistakes or where you have more information to contribute.
http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API

Curious to hear your opinions.

Best Regards,
Silvia.

Received on Friday, 4 February 2011 04:40:02 UTC