This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
According to Ralph Giles at https://bugzilla.mozilla.org/show_bug.cgi?id=886748#c3 if there's ui displayed, which is conditional on 'controls' then aborting in step 1 at http://dev.w3.org/html5/webvtt/#dfn-rules-for-updating-the-display-of-webvtt-text-tracks based solely on the element being <audio>, ie. without checking for the existence of a rendering area which *does* exist when there is a 'controls' boolean attribute, is wrong. Please change the text of that rule to allow vendors to render captions for <audio> elements that have a rendering area.
I'd state it a little more generally. Step 1 assumes <audio> has no rendering area. Does that make sense? <audio controls> has a built-in ui elements which render. It could make sense that <audio><track default></audio> also has a rendering area in which to do caption display. Mardeg, can you explain the use-cases you're trying to address with this, and why e.g. using <video> instead isn't sufficient?
(In reply to comment #1) > Mardeg, can you explain the use-cases you're trying to address with this, When people only record audio of their presentations, and want to use CSS animations/transitions for the image slideshows and/or other javascriptless animations like SMIL in SVG without any video, having the captions for hearing impaired would be ideal. > and why e.g. using <video> instead isn't sufficient? I haven't tested that workaround enough to know the answer to that. Right now I can only speculate that some future curated authoring/hosting sites allow <audio> but not <video>. The key is being able to do it without relying on javascript for when the user isn't in control of settings such as at a kiosk that has javascript off.
You can render captions for audio resources by putting them into a <video> element. The controls are not regarded as a rendering area for the audio - audio is only rendered to the audio device. An <audio> element is not rendered visually unless it has controls, so there is no place to render subtitles into - in particular if you are creating your own controls. Using the <video> element works perfectly fine. You can control the size of the rendering area through CSS. Also, I don't see why sites should disallow the use of <video> when they want to render captions on audio resources.
(In reply to comment #3) > Also, I don't see why sites should disallow the use of <video> when they > want to render captions on audio resources. I was thinking along the lines of soundcloud-like sites that are audio-specific, where people couldn't be trusted to only upload audio to (presuming that playing a video .ogg in <audio> won't show the video), but in any case this is resolved and now it's on the record for people looking it up in future.
It's even explained in a note in the HTML spec. See the first note in http://www.whatwg.org/specs/web-apps/current-work/#the-audio-element . I don't know what else we can do to explain this to people though.