This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
current text: "User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent." recommended change: "User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). Captions, subtitles or other additional visual tracks must remain available and visible at all times. As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent." Filed on behalf of the a11yTF
Given that the layout of additional video tracks is controlled by the page author, any suggestion of how to actually fulfill this requirement?
mass-move component to LC1
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: Please address comment 1 and in addition if you were to reopen please clearly state the issue rather than a text substitution.
Considered at HTML Accessibility Task Force Meeting today. The sense of the meeting was that we may want to keep the non-editorial requirement that is part of this bug, ensuring that controls to activate accessibility features such as extra tracks are always available. There was little support for the explicit requirement that they remain *visible*, but there is an issue of dicsoverability - something available that the user cannot find is of very limited value in solving the problem it is meant to address... http://www.w3.org/2014/02/13-html-a11y-minutes.html#item07
Is your point that: if the video is displayed in a different manner (e.g. full-screen or independent window), any active captions need to continue to be displayed?
Or is it about the controls? (It seems to me that the original bug was for the display of the text, not the controls.)
The original bug as I read it (I don't have the history that produced it, unfortunately), was about the controls. Which need to be available. But I see your point about captions etc actually being visible, and yes I think if they are being rendered they need to remain visible in a transition. Where they are being rendered over the top of the video, this seems only mildly complicated. But where they are being rendered in a separate region, e.g. alongside, I think this is tricky. Is there a way to identify where such things are being rendered? (It must be possible in principle, since they are actually being rendered into *some* space. What I don't know is how difficult it is in practice…)
John's proposed change was explicitly: "Captions, subtitles or other additional visual tracks must remain available and visible at all times." That doesn't indicate "controls" to me, so I assume you want to extend the bug to both: the display of captions as well as the availability of controls. Fair enough. Charles wrote: > Where they are being rendered over the top of the video, this seems only > mildly complicated. But where they are being rendered in a separate region, > e.g. alongside, I think this is tricky. Is there a way to identify where such > things are being rendered? (It must be possible in principle, since they are > actually being rendered into *some* space. What I don't know is how difficult > it is in practice…) The browser never renders captions anywhere but over the top of the video. So we're already covered. So, addressing the issues: 1. Availability of captions when rendered "in manners more suitable to the user" The section in question is about the video element and how the video is rendered within the width and height of the video element. The relevant paragraph merely states that "User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window)." Neither this paragraph, nor this section say or change anything about the rendering of captions. This is simply not the right place to talk about caption rendering. In particular, any caption rendering is already included earlier through the statement: "The video element also represents any text track cues whose text track cue active flag is set and whose text track is in the showing mode, and any audio from the media resource, at the current playback position." How that happens is specified in the "time marches on" algorithm of "4.7.10.8 Playing the media resource". There is no exclusion specified there for where the video is rendered, so all cases are included. 2. Availability of controls I could imagine extending this sentence: "In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent." to include mention of "change the display of closed captions or embedded sign-language tracks" in the e.g. list. Even so: all this is covered much better and in much more detail at http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-controls and it seems strange to repeat this all again. Have you got any examples where this has been an issue? All UAs that I have experienced do the right thing with video in full screen displaying captions and controls.
Closing this again - there has been insufficient information what problem this bug is trying to get solved.
Léonie to figure this out and move to github
Migrated to HTML: https://github.com/w3c/html/issues/173