This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5758 - <audio> and <video> do not have sufficient support for synchronized accessibility content
Summary: <audio> and <video> do not have sufficient support for synchronized accessibi...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: https://www.w3.org/Bugs/Public/show_b...
Whiteboard:
Keywords: a11y, a11ytf, media, PFWG, TrackerIssue
Depends on:
Blocks:
 
Reported: 2008-06-15 01:36 UTC by Jim Jewett
Modified: 2013-03-19 23:28 UTC (History)
17 users (show)

See Also:


Attachments

Description Jim Jewett 2008-06-15 01:36:22 UTC
The new <audio> and <video> elements do not permit fallback content.  

This is a regression from the more generic <object> (though not from <embed>).

The reasoning is that authors SHOULD use accessibility aids built into the underlying media.  While this is indeed desirable, it is not always possibe -- and relies on the browser being able to interpret the media stream, at least to some extent.

An additional fallback step is required for authors who cannot modify the original stream, and for users of browsers which do not understand the format well enough to extract accessibility information.

The fallback already available for <object> would be sufficient, as would a more specialized element such as the sometimes proposed <alt>.
Comment 1 Ian 'Hixie' Hickson 2008-06-15 02:12:35 UTC
<video> and <audio> do support fallback content for user agents with no video and audio support. Just put the fallback contents in the elements.

We will have a format that all UAs support, and that will be the fallback to use when this is deployed. So there is no concern of lack of codec support.

For users who really don't want audio/video but want an alternative form, fallback support wouldn't work, since the UA would quite happily just show the video. Instead, authors should just provide links to transcripts (or whatever). This isn't an accessibility concern (or at least isn't exclusively a concern for disabled users, I should say), because all users sometimes want transcripts.
Comment 2 Jim Jewett 2008-06-15 14:21:29 UTC
(1)  The standard does not require use of the "one good codec"; other codecs are explicitly permitted.

(2)  The "one good codec" has not yet been chosen.  That is largely because there are no such codecs yet -- and that is even without an explicit accessibility requirement on the codec selection.

(3)  There will be user agents that cannot do audio or video because of hardware limits; expecting them to download the entire multimedia stream just to extract the accessibility data is perhaps too optimistic.
Comment 3 Jim Jewett 2008-10-17 02:20:59 UTC
Also note that it is not always possible to edit the original media.  If the media comes from a third party, the web page author may not have the either the legal authority to modify it (copyright concerns) or the technical ability (offsite hosting; proprietary formats).  The web page author must still be able to provide fallback content as appropriate to the web page.
Comment 4 Ian 'Hixie' Hickson 2008-11-22 12:15:33 UTC
"Fallbacks" like transcripts are suitable for everyone, so it doesn't make sense to hide them when the video is available. Transcripts that are alternative media streams should just be listed as <source>s. What other kinds of fallback did you have in mind?
Comment 5 Martin Kliehm 2009-10-29 15:24:18 UTC
I cannot tell what the original aim of the bug reporter were, but regarding accessible fallback this is what WCAG guideline 1.2 is about.[1]

1) If a fallback element is nested within the audio or video element, in some cases the fallback element still needs to be focusable by keyboard, even when the browser supports audio/video. For example Bruce Lawson [2] nests a download link within a video element, so this should be keyboard accessible.

2) If the audio or video content itself is inaccessible due to the nature of the person's disability, accessible alternative content should be available. Accessible alternative content could be a transcript, a textual description, an audio description, captions, or a synchronized sign language video. This content could be linked or otherwise machine-readable bolted onto the element by attributes. Machine-readability is important for assistive technology like screenreaders, but also for search engines. @aria-describedby comes to my mind for text, but @alt or @longdesc could also be appropriate. Synchronized multimedia formats need other attributes to be associated with the original audio/video.

For example a link to a transcript would be sufficient, but users should be able to select if captions are displayed, choose from a range of several captions in multiple languages, and if a sign language interpretation is available this could be displayed as picture-in picture. Bruce Lawson writes that he expected the @controls to specify this, alas this is not yet the case.[2]

It should be noted that accessing alternative content via controls is important for all users, so it would be counter-productive to make them only available if assistive technology devices are present. Deaf users just need a way to enable captions, and so do users who don't have any audio equipment.

Regarding captions there are several competing formats: DFXP [3] as a W3C standard, YouTube officially supports SubViewer and SubRip, inofficially also SAMI and SMIL, but there's also DAISY, QTtext, DVB, TimedText, EBU, SCC, Kate, CMML, SSA, MicroDVD, USF, and VOBSub, among others. I would expect browser vendors to agree on a set of supported formats.

From an author's perspective there need to be easy methods to add such content; editing a link or adding an attribute that refers to another file is reasonable, but embedding captions within a video file could be beyond their abilities.

[1] http://www.w3.org/TR/WCAG/#media-equiv
[2] http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/
[3] http://www.w3.org/TR/ttaf1-dfxp/
Comment 6 Martin Kliehm 2009-10-29 21:02:32 UTC
Example:

-  BBC video with timed text, synchronized to chapters:
   http://open.bbc.co.uk/rad/demos/html5/rdtv/episode2/index.html

But it doesn't end here. What we will see often is a combination of video and canvas. Although a video element might be present what we actually see could be video in a canvas. Just bear that in mind when solving bug #7011.

1. Content Injection:
   http://people.mozilla.com/~prouget/demos/DynamicContentInjection/play.xhtml

2. Filters:
   https://developer.mozilla.org/En/Manipulating_video_using_canvas
   http://blip.tv/file/1881590

3. Face recognition and social media layers:
   http://blip.tv/file/2265515

4. Dailymotion (huge French video site) demo in combination with JavaScript,
   SVG, CSS3, and canvas control elements (volume slider):
   http://www.dailymotion.com/openvideodemo

  
Comment 7 Michael Cooper 2009-11-03 21:21:15 UTC
PFWG is interested in this issue. A group has formed to explore the requirements and solutions. A preliminary meeting was held 1 November 2009 <http://www.w3.org/2009/11/01-media-minutes>. The work will continue in the HTML Accessibility Task Force. Note ISSUE-9 (currently "raised") is also relevant.
Comment 8 Laura Carlson 2009-11-04 00:13:48 UTC
Multimedia Accessibility <Audio> <Video> Wiki Page
http://esw.w3.org/topic/HTML/MultimediaAccessibilty
Comment 9 Ian 'Hixie' Hickson 2010-01-04 08:33:00 UTC
(In reply to comment #5)
> 1) If a fallback element is nested within the audio or video element, in some
> cases the fallback element still needs to be focusable by keyboard, even when
> the browser supports audio/video. For example Bruce Lawson [2] nests a download
> link within a video element, so this should be keyboard accessible.

That's a user agent implementation issue. Since the children of <video> are only exposed to users of UAs that don't support <video> at all, the HTML5 spec can't do much about it anyway  if it could, the UAs would just implement <video>.


> 2) If the audio or video content itself is inaccessible due to the nature of
> the person's disability, accessible alternative content should be available.

This is possible (indeed, easy): just include such content, or links to such content, in the page (not inside the <video> element).


> Accessible alternative content could be a transcript, a textual description

Both of these are already supported, just by regular HTML alongside the <video>. No special feature is needed to enable this.


> an audio description, captions, or a synchronized sign language video.

These are features of the video formats themselves. We haven't yet resolved the format issue. If we can't resolve it, and indeed even if we can, in due course, once browsers implement what is already specced to an adequate level, we will be introducing explicit syntax for time-synchronised captions, sign language insets, etc. This isn't fallback, however, so is out of scope for this bug.


> This
> content could be linked or otherwise machine-readable bolted onto the element
> by attributes. Machine-readability is important for assistive technology like
> screenreaders, but also for search engines. @aria-describedby comes to my mind
> for text, but @alt or @longdesc could also be appropriate. Synchronized
> multimedia formats need other attributes to be associated with the original
> audio/video.

It's unclear which of the many features discussed above this is referring to. Each of the features above have different needs, so it would be inappropriate to address them all the same way.


> For example a link to a transcript would be sufficient, but users should be
> able to select if captions are displayed, choose from a range of several
> captions in multiple languages, and if a sign language interpretation is
> available this could be displayed as picture-in picture. Bruce Lawson writes
> that he expected the @controls to specify this, alas this is not yet the
> case.[2]

It's unclear exactly what is missing here. What is stopping user agents from supporting captions today, for instance?

This is out of scope of this bug, though, which is about fallback. I would encourage you to file very specific bugs on each specific issue, rather than a single bug for the entire area.


> It should be noted that accessing alternative content via controls is important
> for all users, so it would be counter-productive to make them only available if
> assistive technology devices are present. Deaf users just need a way to enable
> captions, and so do users who don't have any audio equipment.

Indeed. This is possible today, and needs no author involvement.


> Regarding captions there are several competing formats: DFXP [3] as a W3C
> standard, YouTube officially supports SubViewer and SubRip, inofficially also
> SAMI and SMIL, but there's also DAISY, QTtext, DVB, TimedText, EBU, SCC, Kate,
> CMML, SSA, MicroDVD, USF, and VOBSub, among others. I would expect browser
> vendors to agree on a set of supported formats.

Format decisions are an outstanding issue currently, and there is work ongoing to resolve it.


> From an author's perspective there need to be easy methods to add such content;
> editing a link or adding an attribute that refers to another file is
> reasonable, but embedding captions within a video file could be beyond their
> abilities.

On the medium term, we will be adding features for external captions and the like. However, it would be harm accessibility of <video> on the Web on the short and medium term if we were to add it today, before browsers have correctly implemented the existing requirements. When browser vendors work on this feature, we want them to be focused on it  we don't want it to be just one more item on a long list of features that they have to all implement at once to get <video> support.


In conclusion, I think the spec as is has suitable support for _fallback_ for <video> and <audio>, though I agree that it is far from a comprehensive solution. I do not think, however, that it is in anyone's interests for us to add more features to make this simpler at this time, since they would end up misimplemented and would unintentionally harm accessibility. This doesn't just apply to these accessibility enhancements, by the way; we've delayed a whole bunch of features that make certain effects simpler while we wait for implementations to catch up.

Also, it's worth noting that as it stands today, authors are very unlikely to make immediate extensive use of <video> anyway. We haven't even found a common codec yet. Therefore in practice the lack of easy-to-use accessibility hooks does not actually have much of an effect at this time.

Here is what I propose as a way forward for this general topic:

- UAs continue to implement <video> such that the implementations reach a high enough caliber that there are no longer major bugs that would distract from additional feature work.
- in the meantime, we experiment with finding the right API, markup, and formats for captions and other time-linked annotation data.
- for the few early-adopter authors making immediate use of <video>, we encourage either the use of scripts that layer subtitles (etc) over video, or the use of subtitles embedded within the video files as separate text tracks.
- once UAs have stable high-quality implementations of the feature set in the spec today, we add external subtitle (etc) support to the spec.


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: Partially Accepted
Change Description: none at this time
Rationale: see above
Comment 10 Laura Carlson 2010-01-12 13:28:10 UTC
Could "Resolution: LATER" be defined for this bug? 

Is there a ballpark date? Does it mean before HTML5 last call? Or does it mean HTML6? 

Thanks.
Comment 11 Ian 'Hixie' Hickson 2010-01-12 21:49:21 UTC
It depends on implementations, as described in detail in comment 9. The best way to help implementations reach a reliable interoperable state faster is to write test cases and file bugs on implementations.
Comment 12 Michael Cooper 2010-02-04 16:36:15 UTC
HTML Accessibility Task force making this a formal tracked bug for the TF.
Comment 13 Michael Cooper 2010-02-04 16:42:37 UTC
Removing myself from cc list, default on bug edits is to add, but I'm only acting on behalf of HTML A11Y TF which is already cc'd.
Comment 14 Silvia Pfeiffer 2010-02-07 01:36:15 UTC
The discussions on this bug have touched multiple topics related to media and accessibility.

I'd like to propose this bug to focus on the support of synchronised accessibility data (captions, subtitles, audio description, sign language) - both embedded in stream and external.

In particular, this bug is not about "fallbacks" (and possibly the word "fallback" should be replaced with "support" in the title).

As for all the other topics that this bug has touched upon, here is what I took out:
* choice of a baseline code - not something we can make any progress on through a bug
* video fallback in UAs where video is not supported - already possible
* non-synchronised text alternatives - already possible through putting text or a link next to the video (and possibly using aria-describedBy to link it to the video)
* access to captions/subtitles available in media files that a UA does not support (e.g. MPEG with subtitles in Firefox) - is simply not technically possible
* @alt attribute - has been discussed in WHATWG, see thread at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021865.html; basically, the following attributes already provide what is required: @title, @aria-label, @aria-describedby

Hope this answers some questions and lets us move to the core accessibility issues for media elements that are still open and that Ian proposed a process for how to address.
Comment 15 Maciej Stachowiak 2010-03-14 13:14:17 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, 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

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 16 Michael[tm] Smith 2010-03-14 13:33:02 UTC
http://www.w3.org/html/wg/tracker/issues/9
Comment 17 Jim Jewett 2010-03-15 13:54:46 UTC
It is formally on me to accept resolution and close, or not.

Given comment 12, I don't feel comfortable doing that.

I won't claim to be fully satisfied, but I'm not sure how to better express my lingering concerns -- so I defer to the HTML Accessibility Task.  When they're satisfied, I'll agree to closure.

Comment 18 Maciej Stachowiak 2010-03-15 14:42:53 UTC
This bug is already marked TrackerIssue so there's no need to close it right now.
Comment 19 Michael[tm] Smith 2010-03-18 15:45:11 UTC
Reopened per discussion on a11y TF telcon 2010-03-18
Comment 20 Maciej Stachowiak 2010-03-18 16:43:22 UTC
Since this bug has already been escalated to the tracker, it's inappropriate to also reopen it.
Comment 21 Maciej Stachowiak 2010-03-18 16:43:41 UTC
(Moving back to VERIFIED)
Comment 22 Laura Carlson 2010-03-22 16:20:52 UTC
(In reply to comment #21)
> (Moving back to VERIFIED)

Maciej set the status of this bug to VERIFIED FIXED after it was reopened through a misunderstanding of the decision process at the a11y teleconference.

Maciej's rationale is that this bug is already escalated to a tracker issue. VERIFIED with a TrackerIssue keyword is indeed the correct state for a bug that has been "resolved" by the editor but has not yet in fact been decided by the working group via the escalation process. Maciej was correct to move the bug back to VERIFIED per HTML working group process.
http://dev.w3.org/html5/decision-policy/decision-policy.html#states-and-keywords

However, Ian did not FIX this bug. It is not FIXED so VERIFIED FIXED is not appropriate. 

It was last labeled VERIFIED LATER.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0395.html

Relabeling this bug VERIFIED LATER as that is was last set it to. Maybe a more appropriate label can be worked out?
Comment 23 Michael Cooper 2011-03-08 16:10:18 UTC
Bug Triage sub-team notes that comment 14 points out that most of the issues can be addressed. What's missing in this bug is a reference to the track element that was introduced later. This element resolves the concerns. No action is required yet as the bug can't be closed until a text format is agreed upon. Verified Later is an appropriate state at this moment.
Comment 24 Silvia Pfeiffer 2013-01-05 03:33:51 UTC
The introduction of WebVTT and <track> with captions, subtitle, descriptions, chapter support, as well as the introduction of the media controller that allows audio descriptions and sign language videos to be synchronized to a media resource should allow this bug to be closed.
Comment 25 Michael[tm] Smith 2013-01-24 07:52:08 UTC
This bug was cloned to create HTML WG bug 19020.
Comment 26 Ian 'Hixie' Hickson 2013-03-19 23:28:30 UTC
Closing per comment 24. Please reopen (or, ideally, open a new bug, since this one is now long) if you disagree.