This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-audio-element Currently, the audio element states about accessibility: "Note: In particular, this content is not intended to address accessibility concerns. To make audio content accessible to the deaf or to those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as transcriptions) into their media streams." This is a somewhat incomplete and unsatisfactory statement, probably because it was written long before we had sorted all the video accessibility issues. Namely: when alternative media streams for an audio resource are provided for the deaf, they would naturally need to be visual, such as sign language tracks or captions. Thus, they introduce a visual component into an otherwise audio-only resource. I can see the following means of providing accessibility for <audio>: (1) When providing sign language or captions as embedded tracks (or through <track>) with the audio resource and intending to have them displayed by default, we require the Web author to publish the resource in a <video> element instead of <audio>. (2) When a sign language track is provided in a separate <video> element, we need to group them together with the multitrack API http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#synchronising-multiple-media-elements . (3) When providing a non-time-aligned text-only replacement for an audio element such as a transcript (or transcription), we should either link to it on-page with an aria-describedby attribute, provide a link underneath the <audio> element, or use the newly suggested @transcript attribute (see bug 12964) if we don't want it displayed on the page. I suggest we add a more complete description of the accessibility capabilities of the <audio> element to this section with recommendations on what to do in which situation.
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: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r6426. Check-in comment: Enumerate the many ways you can make video accessible now. http://html5.org/tools/web-apps-tracker?from=6425&to=6426