- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Aug 2011 23:42:17 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13435 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ian@hixie.ch Resolution| |WONTFIX --- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-09 23:42:16 UTC --- 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: Doing this would be massively complicated. By the time we reach the point where the right video frame is not being rendered, the events have already fired on the cues to tell them that they're no longer active (that has to be the case so that pauseOnExit cues can work). This means the cues might have been changed (e.g. if the script is preparing cues behind the scenes in preparation for going back to play the segment of video, etc). I really don't see how we could cause the cues to display regardless — the captions might be being rendered by the script itself, so we'd have to do something crazily complicated like fake the currentTime back to the time of the last frame, but only for the captions not the buffering... It would be a huge gnarly mess. However, all is not lost — indeed things here are nowhere near as bad as it may seem. In practice, there are two cases where this might happen: if the video runs out while playing, and if the user has seeked. In the normal playback case, the only way this could be visible is if the very next frame after the last frame displayed was the one at which the captions would have gone away anyway. In that case, it really is not an accessibility problem, unless one is going to argue that there is some big accessibility difference between a video stalling at frame 302923 or at frame 302924, which seems unlikely. In the seek case, the user probably explicitly moved the video playhead, so IMHO it's really hard to argue that the user still needs the captions in that case. If the user wanted the old captions, he could just have seeked to the point where those captions were present. Indeed if anything it makes the captioned experience better than the non-captioned experience since it means a user can scrub the seek bar and quickly scan through all the subtitles without having to wait for the video to load. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Tuesday, 9 August 2011 23:42:18 UTC