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.