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

A few quick comments on the second proposal. (This deals only with the markup section, I'm also working on a more detailed discussion for the rendering section).

@name probably ought to be @title - this seems to be closer to the usage of @title on other elements.

You need to mention how the <trackgroup> and <track> elements fit into the content model of the <video> and <audio> element, it's not clear that multiple <trackgroups> for example are legal.

I would prefix the phrase: "The text in a text interval is displayed while the active resource's currentTime is between the start time of the interval but has not yet reached the end time of the interval (a semi-open interval: [start,end) )."
With "Unless the text resource semantics define otherwise,"  since for SMPTE marker time mode in TTML the above is not strictly accurate.

I'd prefer textaudiodesc to just be description.

I'm not sure what "chapters" are in this role list; I suggest they be dropped for the moment. And you might want to merge the lyrics and karaoke class unless there is some essential difference I'm missing. 

Replace the wording of:
"If provided, the @enabled attribute specifies that the track is enabled and should be displayed in an appropriate manner. If the attribute is not provided, the track is not displayed."

With 

"If provided, the @enabled attribute specifies that the track is enabled and is available to be displayed in an appropriate manner. If the attribute is not provided, the track is not available to be displayed  unless the track is enabled dynamically."


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Silvia Pfeiffer
Sent: Friday, April 09, 2010 11:59 PM
To: public-html
Subject: 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 Sunday, 11 April 2010 13:21:39 UTC