Change Proposals toward Issue-9: "how accessibility works for <video> is unclear"

Hi all,

I've just registered two bugs in the bug tracker that go towards
Issue-9 "how accessibility works for <video> is unclear".

There are two change proposals associated with these bugs and the
issue, which have been developed over the last months within the media
subgroup of the Accessibility Task Force.

These change proposals aren't yet an official recommendation of the
TF, but since they haven't changed substantially over the last two
months, it is time to put them in front of a larger technical audience
for further discussion and progress towards inclusion in the
specification.

--------------
Change Proposal 1:
http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9452

This proposal introduces a JavaScript API for media resources that
have more than the usual main audio and video track. The idea is to
introduce a control mechanism for page authors to allow them to
activate / deactivate tracks for display. This is particularly
important since many media resources already contain caption and
subtitle tracks.

The proposal further has a further recommendation to include into the
UI control a menu to enable users to undertake the track activation /
deactivation interactively.
--------------

--------------
Change Proposal 2:
http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9471

This proposal introduces declarative markup to associate external
timed text resources (such as captions and subtitles) with a media
resource. It introduces <track> and <trackgroup> elements to be used
inside media elements and provides some recommendations on how to
render the text resources.
--------------


Note that these change proposals are a first step towards resolving
Issue 9 and will require further specifications.

For example, it is as yet unclear how the timed text fragments (also
called "text cues" or "text intervals") are to be rendered. Should
they be included in plain sight in the DOM? Should they be included in
a shadow DOM? Should they be rendered into an iframe-like construct?
And how would a Web Developer gain access to the text in a text
fragment - should there be a callback?


Any feedback, comments, suggestions welcome!

Cheers,
Silvia.

Received on Friday, 9 April 2010 22:38:13 UTC