This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Full-text non-timed transcripts of audio or video are the only means for some users to consume audio or video content, be it e.g. that they are deaf-blind, or are on a low bandwidth connection, in a text-only browser, or would simply prefer to scan the transcript over spending the time watching the a/v resource. Video publishers that want to publish such full-text transcripts with their video content typically provide a separate resource with that transcript, since it tends to be a lengthy piece of content and it is Web content in its own right. (Note that for on-page content we already have @aria-describedby, so I am only interested in this off-page use case.) There are two ways in which video publishers typically provide the link to an off-page transcript: either in a URL somewhere underneath the video element, or as a user interface element to click to from within the video element. The transcript link in both these cases is not directly part of the video's markup, even if in the second display case the Web developer has made the transcript at least visually a part of the video. There are reasons to actually make a link to a transcript a native part of the video (and audio) element: * discoverability: blind users that reach a video element currently need to search other elements on the page to find the link to the full-text transcript; if it was a native part of the element, its presence could be announced as the user discovers the video * programmatic use: neither screen readers nor crawlers can currently identify such distinct elements on the page as belonging to the video and providing text that is a relevant placeholder for that element (e.g. a search engine can use the transcript for indexing) * design: most Web designers prefer not to have to put an extra element on their Web page just to provide a link to a full-text transcript; if we make it a native part of the audio/video element, we can put the link in the context menu and Web developers don't have to design anything to make it available * embedding: when video elements are embedded into other Web pages by copying the video element markup, the link to the full-text transcript is lost unless it is part of the video element markup Thus the suggestion is to add a @transcript attribute to the <video> and <audio> elements with a URL as the value and a recommendation to UAs add the link in the context menu for these elements or make it otherwise available through the media element controls.
mass-moved 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: Did Not Understand Request Change Description: no spec change Rationale: How do we know this won't suffer the same fate as summary="", longdesc="", cite="", etc?
(In reply to comment #2) > 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: How do we know this won't suffer the same fate as summary="", > longdesc="", cite="", etc? A fair enough question and also the most important issue to worry about with this. I think it does need to be part of the visual presentation and I think the controls are the right place - in addition to the context menu. I can imagine either a special button, but with tight real estate in controls, it could also be in a menu. Since this can be the ultimate fallback for when no video is shown, HTML5-conformant text-only browsers could also display the link to the transcript in place of the video/audio element, making it useful beyond just accessibility. I'm curious what browser developers think about it. Would they (in particular their video controls designers) implement it? Could somebody come up with a nicely designed video control that includes such a button to show that it can be done without cluttering the UI?
See response at comment #3
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: We need implementation experience before we can add this to the spec. Without it, I see no reason why this would not suffer the same fate as similar solutions before it (like longdesc, summary, cite, etc).
If a video publishing site was to add links to transcripts to a custom context menu on videos, would that be sufficient implementation experience?
(In reply to comment #5) > > Status: Did Not Understand Request Add a @transcript attribute to the <video> and <audio> elements with a URL as the value. > Rationale: We need implementation experience before we can add this to the > spec. Without it, I see no reason why this would not suffer the same fate as > similar solutions before it (like longdesc, summary, cite, etc). The Editor's bias against specific accessibility accommodations such as @longdesc and @summary is not a reason to fail to address this requirement. We have evidence that video producers will be creating and subsequently providing transcripts (essentially non-time-stamped captions or subtitles) and so accurate content will be produced at the time of content creation. Best Practices and possibly legislation(s) will require content authors to provide these transcripts to end-users, and a means to directly and programmaticly link the transcript to the video element (without the absolute requirement for on-screen text) is well founded. On 2012-01-06 Anne van Kesteren stated "A standard sets a goal." https://www.w3.org/Bugs/Public/show_bug.cgi?id=13531#c8, and so the need for implementation experience should not be a reason to reject this user-requirement.
Suggested tracker title: Provide a mechanism for associating a full transcript with an audio or video element. Suggested tracker description: Full transcripts give people with disabilities a way to access audio/video content. Transcripts are often provided as a separate resource, because they're often too lengthy to be included on the same page as the audio/video they're associated with. A mechanism that creates an association between an audio/video element and a full (off page) transcript would have many benefits. These include discoverability for assistive technology users, programmatic identification for search engine indexing, design asthetic, and content syndication or embedding..
raised as issue https://www.w3.org/html/wg/tracker/issues/194
Some analysis is at http://www.w3.org/html/wg/wiki/ISSUE-194/Research Another proposal for a new element is at http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP The a11y TF is preparing to make a consensus Change Proposal in the coming week: http://lists.w3.org/Archives/Public/public-html-a11y/2012May/0079.html
Discussed in HTML Accessibility TF Meeting on 06 Feb 2014 http://www.w3.org/2014/02/06-html-a11y-minutes.html#item05 RESOLVED to consider for HTML 5.1 Moved to HTML a11y Task Force component on 08 MAR 2014 for additional info.
There is a spec for ways of explicitly linking a transcript, but it's in incubation hoping for some implementation experience: https://www.w3.org/TR/html-transcript-src/