This bug is relate to HTML-ISSUE-9 video-accessibility
http://www.w3.org/html/wg/tracker/issues/9

I continue to believe that this new 'kind' attribute is backwards, and that we should use media queries here to determine what need the track satisfies.  They can then also be used (a) to position the track etc. and (b) adjust the rest of the page to suit.

(In reply to comment #2)
> I continue to believe that this new 'kind' attribute is backwards, and that we
> should use media queries here to determine what need the track satisfies.  They
> can then also be used (a) to position the track etc. and (b) adjust the rest of
> the page to suit.

Media queries are about what media type something is rendered onto, not what content type is being rendered. I don't understand how the knowledge where we have captions, subtitles or descriptions helps in deciding where to position a track differently on different devices and what effect that would have on the rest of the page. Can you provide an example not just of the markup but also of the consequences?

Silvia says (correctly) that kind indicates the type of media, whereas media queries are about what output is desired.  Yes, I am suggesting to turn it upside down; label the tracks (and sources) with what *need* they meet, rather than with what they contain.  Then, for example, if an auxiliary track is enabled by its media query being satisfied (query is true if the user desired sub-titles, for example), it can be positioned suitably, outside the rendering area of the main video -- and other elements on the page can also be adjusted in position, or even appear.  For example, there might be a caption somewhere "Signing done by Eliza Bloggs, used with permission." -- a div that would only appear (has the same media query) if the sign language track is also shown.  The rest of the page can now adjust layout and so on...

(In reply to comment #4)
> Silvia says (correctly) that kind indicates the type of media, whereas media
> queries are about what output is desired.  Yes, I am suggesting to turn it
> upside down; label the tracks (and sources) with what *need* they meet, rather
> than with what they contain. 

Whether we label these resources based on 'type' or 'need-met', it seems that we would need a shared taxonomy of terms for interoperability.  To date we have worked on the assumption of types, and this bug seeks to expand the taxonomic list of types to address the types of content identified to address various user needs. 

Given the diverse combinations of user needs that may exist, I fear developing a common taxonomic list from that perspective would prove extremely complex, but I have not embarked upon that thought exercise. David, do you have any ideas here?

Is there any documentation documenting the use cases behind, and the definitions of, the various kinds listed in comment 0? I looked at the proffered document but it doesn't seem to list rationales or describe what these kinds are in any kind of detail.

(In reply to comment #6)
> Is there any documentation documenting the use cases behind, and the
> definitions of, the various kinds listed in comment 0? I looked at the
> proffered document but it doesn't seem to list rationales or describe what
> these kinds are in any kind of detail.

The Checklist provided is a derived from the Media Accessibility User Requirements (http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements). 

The different kinds of content are detailed starting at: 
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Described_video
For ease of use, each content type in the Checklist links back to the fuller explanation/use-case/documentation in this document (as, for example, the link to Described Video just provided)

The HTML5 Accessibility Task-Force (Media Sub-Team) reported the publication of this document in August, 2010 (http://lists.w3.org/Archives/Public/public-html/2010Aug/0327.html) At that time, the sub-team wrote:
"We are to the point where we need to begin engaging the wider HTML 5
community in understanding the ramifications of these requirements, and
in collaborating on appropriate solutions. Thus, we invite you to become
familiar with the requirements, ask questions, offer suggestions, and
generally engage with us on next steps."

We did receive some minimal feedback and I believe it was also a topic of discussion at TPAC in November. A this time it is presumed accurate and complete, and outside of controversy.

Adding the a11yTF keyword for the bug-triage sub-team, acknowledging that this could considerably enhance accessibility.

(In reply to comment #0)
> The current @kind attribute of <track>
> (http://dev.w3.org/html5/spec/Overview.html#the-track-element) only allows for
> the following kinds of content:
> 
>  Subtitles
>  Captions
>  Descriptions
>  Chapters
>  Metadata
> 
> The Accessibility Task Force Media Sub-Team have identified the following types
> of alternative content that should be made available to meet all User needs:
> 
> Text-based:
>  Text video description

"text video description" is identical to "description" - already covered


>  Extended text video descriptions

This adds the pausing feature to "description", i.e. a means to make a description cue last longer than the available synchronized time with the video. IMO it's a feature that should be available to all "description" kinds of content, so doesn't need a new kind.


>  Captioning

"Captioning" is identical to "Captions" - already covered


>  Enhanced captions/subtitles

This has been a matter of discussion for a while and the answer has thus far been to use the "Metadata" type and run your own enhanced captions/subtitles.


>  Transcripts

"Transcripts" are not provided in chunks in sync with the video, but as a block of text, so these do not need to be provided through @kind. Example uses of transcripts are shown here:

- external linked resource:
http://www.annodex.net/~silvia/a11y_bcp/demo1_transcript.html

- scrolling transcript:
http://www.annodex.net/~silvia/a11y_bcp/demo2_transcript.html


 
> The enumerated list table should be extended to address these KINDS of
> alternative content.

Other than extended captions/subtitles, which can right now be satisfied through "Metadata", nothing is missing IMHO.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 9.

Given that this *may* be impacted by current discussions underway now on the W3C public_html mailing list (http://lists.w3.org/Archives/Public/public-html/2011Feb/0205.html) the timing for dismissal of this bug is inappropriate. Reopened until such time as a decision on how to support the Media_Multitrack_Media_API has been resolved.

mass-moved component to LC1

John, this bug is waiting on info from you; in particular, responses to Silvia's comment #9.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: no new information since comment 10