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

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


Martin Kliehm <martin.kliehm@namics.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin.kliehm@namics.com
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |




--- Comment #5 from Martin Kliehm <martin.kliehm@namics.com>  2009-10-29 15:24:18 ---
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/


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 29 October 2009 15:24:29 UTC