This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For accessibility purposes, but also for other annotation purposes, timed tracks for media elements are often not independent, but are provided at different resolution levels. For example, a recording of a book reading can have chapters and paragraphs to navigate between. Or a movie can have shots, scenes and chapters. Or an opera can have scenes and acts. I expect them to be marked up as separate text tracks. It must thus be possible for accessibility purposes to switch between these levels easily using a keyboard and this switching to affect the playback position in the media resource. For example, I envisage a hierarchical relationship between such timed tracks and a shortcut key to switch up and down this hierarchy. I am not sure how this can be implemented best. Maybe it requires extra markers on the tracks to signify that tracks relate to each other and how - something like the z-level in CSS. Also in this context: the usefulness of timed track cues for navigation purposes cannot be under-estimated. If, for example, we can mark up cues with a semantic meaning, then we can navigate just between those cues that match a certain semantic. We could, for example, navigate to all the advertising blocks in a recording from TV (or alternatively to all the non-advertising blocks). Even though these cues would all live in the same timed track, navigation should be enabled for such fine-grained access. This may well need to be something that is added by browsers to the controls on a media element, but may also require extra markup - I am not sure yet how to solve this best. (More information in this area at: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Content_navigation_by_content_structure)
Could you provide an example of software that does what you describe? I'm not really understanding what it is you want browsers to do here. Is the request to have browser UI to do something, or would it be sufficient to have an API to allow scripts to provide such a feature?
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: Did Not Understand Request Change Description: no spec change Rationale: see comment 1
** This has been identified as a probable issue within HTML5 by the media sub-team of the Accessibility Task Force. The bug has been filed at this time to meet the October 1st cutoff date, with more details forth coming. **
NEEDSINFO is the correct state for a bug "with more details forth coming". Please do not REOPEN until sufficient information is present for the bug to be evaluated.
As "more details [are] forth coming", TrackerRequest is premature.
Sorry about the delayed reply. As an example for a software/system that provides this functionality, you should look at Daisy players, e.g. http://www.youtube.com/watch?v=WG9Gc-huujk . In this example, a audio book (which you can regard as a single, lengthy audio file) is shown to have several different ways of navigating. The navigation is provided through different markup. For example, it says it has different navigation levels. In HTML5 they would be provided through multiple text tracks that are of @kind=chapter and thus provide navigation markers. Now, if for example one navigation level is book chapters and the next is book subchapters, then in HTML5 we would provide them as two different text tracks of @kind=chapter and @label="book chapter" and @label="book subchapter" respectively. We have, however, no means to determine that one is a higher resolution to the other. A blind person would want to know this and would want to be able to navigate e.g. through arrow up/down between the different resolution levels and e.g. through arrow forward/back within a chapter track. While the navigation itself is a UA issue, the need to mark one track as related to the other and as a sub-division of the other is a markup/API issue. I don't know the best way to solve this. Maybe it is already solved through the way in which TextTracks are ordered in a media element's list of text tracks, i.e. if a @kind=chapter track is earlier in the TextTracks list, then it is implied to be of a higher hierarchical level than the next. Thus, a UA is expected to allow a blind user to navigate between these tracks in their order as given in the list of text tracks. However, there is only limited control over a TextTrack's position in the list of text tracks, in particular when they originate from different sources. Therefore, an explicit numbering (similar to the z-level for CSS blocks) might make more sense. Either way, a mention of how a UA should interpret the list for navigation purposes is important.
Bug triage sub-team marking as reopened since Silvia appears to have provide the requested information in a new comment.
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: This seems like a really esoteric feature, certainly not a "v1" feature (we could easily add this in a future revision of the language). Having said that, I'm not actually sure it's worth addressing explicitly at all. In the example, the software seems to just have multiple chapter tracks a couple of implied ones for media and file selection (flash card vs CD), then the tracks in the currently selected media file, which, for the "Understanding Health" book in question seems to consist of four tracks named "level 1", "level 2", "level 3", and "pages", and finally a couple more implied tracks called "time" and "bookmarks". This is entirely handled already by <track kind=chapter label> in HTML as far as I can tell. I think before adding this feature we would need to have much more compelling use cases and a much more concrete explanation of how it would improve accessibility relative to what we have today.
This has been identified by the Accessibility Sub-Team as a Functional Requirement for Media Accessibility: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Content_navigation_by_content_structure http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Granularity_level_control_for_structural_navigation Related: Issue 9 http://www.w3.org/html/wg/tracker/issues/9
(In reply to comment #8) > 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: > > This seems like a really esoteric feature, certainly not a "v1" feature (we > could easily add this in a future revision of the language). To blind people the need to navigate between different resolution levels on the timeline of a audio/video resource is actually very fundamental. This is not a request for a big change - just for an attribute on <track> to identify at what hierarchy level this track is supposed to be interpreted in relation to the other <track> elements, such that keyboard-driven track switching (typically up/down arrow) knows which are the adjacent tracks. > Having said that, I'm not actually sure it's worth addressing explicitly at > all. In the example, the software seems to just have multiple chapter tracks > a couple of implied ones for media and file selection (flash card vs CD), then > the tracks in the currently selected media file, which, for the "Understanding > Health" book in question seems to consist of four tracks named "level 1", > "level 2", "level 3", and "pages", and finally a couple more implied tracks > called "time" and "bookmarks". This is entirely handled already by <track > kind=chapter label> in HTML as far as I can tell. The bit that is not supported is the switching between the tracks in a controlled manner. If we could safely assume that the hierarchical relationship between the tracks can be given through their order in the HTMLMediaElement's list of tracks, then a keyboard-driven track switching wouldn't need any additional information. However, a track from in-band could logically be a super-track to an externally specified one, so we can't do it in this way. A simple additional attribute seems adequate. > I think before adding this feature we would need to have much more compelling > use cases and a much more concrete explanation of how it would improve > accessibility relative to what we have today. I guess implementation of the <track> element and the different kinds of tracks is necessary first before we can show the limitations for keyboard-driven track switching and navigation. In my opinion we can leave this bug open until such time and get back to the discussion then.
Raised as an issue: http://www.w3.org/html/wg/tracker/issues/163