HTML5 <audio> fallback test

updated: April 13, 2011

The HTML5 spec says the fallback content of the audio element is for older browsers, and that’s it. A note explains that it shouldn’t be used as an accessibility mechanism.

While I don’t disagree with this take on fallback content and the means to provide accessibility for audio content, there is a use case that is not addressed here:

The HTML author is not a web developer, and wants to write simple HTML code. Say the author is a hobbyist, a writer, or anyone wanting to write a small website.
Said author only has one version of the audio content, and is not comfortable with converting in multiple formats (or managing a collection of files in 2-3 formats).
Said author uses only one audio file, and provides a link to the audio file as fallback content.

Result: Current web browsers will display an audio element in the page even if they know they do not support the provided format(s). The fallback content is never used, as per the spec. A quick look at Safari 5, Firefox 4, Chrome 10 and Opera 11.10 shows that browsers fail to show very clearly that they will not be able to play the audio. Site users are likely to click on the “play” buttons that the browsers do provide, and nothing will happen.

This has been discussed on the WHATWG mailing list before.

Simple tests

With controls

<source src="test.fiction" type="audio/fictitious">
(The file test.fiction is 0 bytes.)

No controls

A audio element with no controls attribute is supposed to be hidden, and used by script, right? So I guess displaying the fallback in this case would be wrong, even if the spec is changed to reflect the use case above.

<source src="test.fiction" type="audio/fictitious">
(The file test.fiction is 0 bytes.)

Credits

Music is I am a Sack by pompey (in Pompey versus Vesuvius).

Thanks to Anthony and Jérémie for pointing me to the spec. :)

Thanks to Xavier for pointing existing WHATWG discussions.