I don't see how it follows from the requirement that media queries be used. Browsers could just as well let the user set preferred language and indicate if they want HoH cues or not. Neither of these can be expressed by media queries.

Also, I don't understand what "in cases where the alternative content has different dimensions than the original content, how the layout/reflow of the document should be handled" means in practice. Layout is determined by CSS, it would be strange to have it depend on a user preference. User CSS might work, although it's not clear what the actual requirement is. (To avoid overlap?)

I do not understand how Media Queries can help here. Users do not set/manipulate Media Queries, that is not how they work. (Are you trying to convey a proposal from David Singer by any chance?)

answering Anne, I think he may be, yes.

The basic idea is to mark <track> and <source> elements with a media query that is satisfied when a particular accessibility need is, or is not, requested.  That would make it possible to say "don't show this if the user is susceptible to repetitive stimulation", it would make it possible to say "this text <track> meets a sub-titling need (in Swahili)", and so on.  Media queries also make it possible for the rest of the page, including the layout, to respond as needed.

My understanding of DAC-2 was that we are going to provide a menu that displays all available tracks to the user to let the enable/disable the track display.

On top of this, there will be user settings in browsers for the preferred tracks to be active by default. If the kind/lang combination of a track matches a user's preferences, the track will automatically be turned on.

As for the "repetitive stimuation" issue - I guess what you are saying is that a video that e.g. provides strobelight, and can cause seizures, should be marked as such and not play for people who may have indicated such an anit-preference in their browser. Are there any other such use cases where videos are dangerous to certain user groups and must not be shown to them at all (apart from porn, I guess)? I don't really think media queries are the right solution for that (since it's not a property of the display media that we are filtering on, but a user preference). I think it might be better to introduce another attribute for such things, something like @indication which can indicate what audience to avoid (e.g. adult, strobe etc).

Haven't made up my mind on this though, just thinking out loud...

Silvia: you're right, in that this is a slight extension of the 'display' to include the user's reception of the presented material, so it is a conceptual extension of media queries.

then, on "On top of this, there will be user settings in browsers for the preferred
tracks to be active by default. If the kind/lang combination of a track matches
a user's preferences, the track will automatically be turned on." -- we have a system that delivers an on/off signal, and it's called media queries.  Rather than inventing a new 'type' indicator, which is what we're doing, I'd like to explore using the existing one. 

Particularly, this (a) allows the rest of the page to respond as well (so, trivially, I could show something that confirms I see your preference "captions enabled") and (b) if we can 'style' the tracks in the video element as well as the element itself, then (perhaps) the layout of that element and the rest of the page can change (allowing by-side captioning rather than overlay, if desired, for example).

that was my broad vision, anyway...

(In reply to comment #5)
> Silvia: you're right, in that this is a slight extension of the 'display' to
> include the user's reception of the presented material, so it is a conceptual
> extension of media queries.
> 
> then, on "On top of this, there will be user settings in browsers for the
> preferred
> tracks to be active by default. If the kind/lang combination of a track matches
> a user's preferences, the track will automatically be turned on." -- we have a
> system that delivers an on/off signal, and it's called media queries.  Rather
> than inventing a new 'type' indicator, which is what we're doing, I'd like to
> explore using the existing one.


It's not really a new system - browser preference language settings already influence what we see on the Web. The @kind attribute just adds the type of accessibility content to this existing feature.

 
> Particularly, this (a) allows the rest of the page to respond as well (so,
> trivially, I could show something that confirms I see your preference "captions
> enabled") and (b) if we can 'style' the tracks in the video element as well as
> the element itself, then (perhaps) the layout of that element and the rest of
> the page can change (allowing by-side captioning rather than overlay, if
> desired, for example).
> 
> that was my broad vision, anyway...

I'm curious what you mean by "the rest of the page responds" and "style the tracks". Are you talking about exposing the state to JavaScript, such that a JavaScript developer can then grab the captions in display them side-by-side rather than as overlay as they are displayed by default? Can you give a concrete example where the @media query works but the @kind/@lang attribute doesn't?

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 yet
Rationale: Before we apply this to <track>, I think we should wait to have proven that it works with <source>. We can always add it to <track> later if it turns out that this works well.

I'd like to point out that bug 11593 partly addresses the same issue using the @kind attribute: a user needs to be enabled to make an informed decision which tracks are available and what kind of content they represent.

What isn't addressed by the other bug is the functionality of user preferences that are translated by the browser into some kind of default user style-sheet.

But the analogy of language preferences doesn't translate well because they also come with a priority, so I believe the concept of media queries doesn't quite reflect this. A media query is binary, true or false, but doesn't ask if "extended audio descriptions" are priority 0.9 while "audio descriptions" are 0.7.

The bug-triage sub-team doesn't think this particular bug needs to be HTML Accessibility Task Force priority. We think there's a consensus that taking user preferences as default settings would benefit users, but there's disagreement if media queries are the right tool.

Assigning to John Foliot to push the issue in the media group.

I think that this is being addressed in a different way so we should close it.

mass-move component to LC1