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

Sorry, this was supposed to go to the HTML WG. But you might all here
as well be aware of it.

Cheers,
Silvia.

On Sat, Apr 10, 2010 at 8:37 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> 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 23:00:08 UTC