[Bug 5758] insufficient accessibility fallback for <audio> or <video>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5758


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |LATER




--- Comment #9 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-01-04 08:33:00 ---
(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


-- 
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 Monday, 4 January 2010 08:33:02 UTC