Could captions be an alternative for time-based media SC 1.2.1 with audio-only content about wcag HOT 12 CLOSED

Official Working Group Response

A media alternative is specifically allowed for audio-only content in 1.2.1 because there is an assumption there is no place to display captions.

audio-only
a time-based presentation that contains only audio (no video and no interaction)

If you are positing a situation where 'only' audio content is played but captions can be displayed, then this is no longer "audio-only" but instead is synchronized media ("audio or video synchronized with another format for presenting information..."). As such, yes, captions can be used for 'audio only' where technology supports it, but in that case it is assessed against 1.2.2 Captions (Pre-recorded).

from wcag.

personally agree that captions would be a good alternative, but can see how that stretches the definition for https://www.w3.org/TR/WCAG22/#dfn-alternative-for-time-based-media

might be worth tweaking the wording gently?

from wcag.

@patrickhlauke after discussion in the task force, I tweaked the language so that are response is not 'yes, you can use captions to meet 1.2.1' but instead 'if you are using captions, they are synchronized, and therefore are measured under 1.2.2 Captions.

@dbjorge please confirm my changes match the basic conclusion of the task force.

from wcag.

If you are positing a situation where 'only' audio content is played but captions can be displayed, then this is no longer "audio-only" but instead is synchronized media ("audio or video synchronized with another format for presenting information..."). As such, yes, captions can be used for 'audio only' where technology supports it, but in that case it is assessed against 1.2.2 Captions (Pre-recorded).

There's an issue in the HTML spec where the <audio> element supports text <track> elements, but doesn't create any space on the page to display text captions/subtitles/descriptions. The recommendation from the HTML group has been that, if you have an audio-only track but also have a text track, page authors should play the media in a <video> element instead of an <audio> element. This creates an area on the page where a text track can be displayed. (And also potentially the display of a "poster" still image, such as album cover art, although there's a problem with doing that from an accessibility perspective because the <video> element doesn't provide any native way to supply alt text for the poster image. The expectation is that the poster image is part of the video, so it doesn't need separate alt text, but that isn't true for an audio-only track).

The guidance from this WCAG group on this needs to be very clear that 1.2.1 requires a "document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction" and that providing a text caption track doesn't actually meet that requirement - it moves the content from being considered "audio-only" to being "synchronized media," at which point the media needs to meet 1.2.2, 1.2.3, and 1.2.5 (at Level AA). That's a unique situation - adding a specific feature with the intent to improve accessibility changes which WCAG S.C. the content needs to meet!

This group also needs to think about what to do about that "poster" image in a <video> element if the <video> element is used to play audio-only plus text captions content - how will page authors provide alt text for the image, separate from labeling the <video> element (with title, aria-label etc.), which would surely need to label the name of the audio track / song, not the image?

from wcag.

This same logic means that if you synch via highlight the document transcript text being spoken with the audio then you suddenly change the nature of the content to synchronized media as well. Although in that case you could then argue that it's a media alternative for the document - but then you'd need to clearly label it as such.

This line of thinking that an alternative then changes the nature of the content seems like a hole in the wording of the criteria and discourages people from creating anything other than non-interactive transcript type documents. It discourages synchronizing text with audio or video.

from wcag.

That's a unique situation - adding a specific feature with the intent to improve accessibility changes which WCAG S.C. the content needs to meet!

I don't think that's unique, adding a video of sign-language can trigger new requirements that weren't there without the video.

Adding diagrams / infographics to support a complex section of text adds alt-text requirements.

Conforming alternative versions mitigates this is some situations, but you can get cascades.

from wcag.

@alastc :

I don't think that's unique, adding a video of sign-language can trigger new requirements that weren't there without the video.

Can you explain that a little more? What other SC does a video need to meet if a video of sign-language is added to it (I'm assuming you mean to meet 1.2.6)? Or are you thinking about adding a video of sign-language where there isn't any other video related to it?

Adding diagrams / infographics to support a complex section of text adds alt-text requirements.

An author wouldn't be adding "diagrams / infographics" to a page "to support a complex section of text" in an attempt to meet a specific WCAG SC, though, would they? They would be doing it for reasons other than accessibility. That was my point - if an author has a "Prerecorded Audio-only" track according to the definition in 1.2.1, and they add captions thinking it will meet 1.2.1, but doing so stops it from being "Prerecorded Audio-only" and therefore 1.2.1 doesn't apply and 1.2.2 applies instead, I don't think that's the same as adding "diagrams / infographics to support a complex section of text"

from wcag.

providing a text caption track doesn't actually meet that requirement

@OwenEdwards the HTML5 track element states "The track element allows authors to specify explicit external timed text tracks for media elements."

It specifies a kind attribute that supports five keywords, one of which is "captions". So the technique seems to match the interpretation in the draft response -- when an audio element has a track child of kind "caption", the outcome is expected to be a synchronized caption track.

In the scenario I believe you're describing, where the audio is played without a visible caption due to technology limitations, then it would be an audio-only, and the content provided in the `track', assuming it is accurate, seems to fully meet the definition of "alternative for time-based media":

document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction

At any rate, specific technical considerations are normally tackled in the techniques. I note there is an advisory technique for the track element, https://www.w3.org/WAI/WCAG21/Techniques/html/H96, but it is currently specifically for video-only, not audio only. There IS a technique using track, but it is only in 1.2.2: https://www.w3.org/WAI/WCAG21/Techniques/html/H95 .
Another option would be to put information in to G158: Providing an alternative for time-based media for audio-only content.

If you feel any of these documents can be updated to address your concern, please feel free to open an issue specifically about that

from wcag.

There seems to be some confusion on whether the audio element supports captions - aXe has test a requiring captions for audio elements - https://dequeuniversity.com/rules/axe/4.9/audio-caption - I believe there was an ACT rule for it previously as well.

from wcag.

In the scenario I believe you're describing, where the audio is played without a visible caption due to technology limitations, then it would be an audio-only, and the content provided in the `track', assuming it is accurate, seems to fully meet the definition of "alternative for time-based media":

I thought there was a separate discussion where it was discussed that alternatives for SC 1.2.1 video only didn't not need to be visible - but alternatives for 1.2.1 audio-only did need to be visible. If the captions are not visible to anyone but provided, how would a person who is deaf or hard of hearing read them? It seems like this approach of an invisible caption track would fail the accessibility supported conformance requirement.

from wcag.

As agreed in the Friday call, I checked the 1.2.1 Understanding text and drafted a note to take care of alternatives to audio provided as caption via the track element.

from wcag.

@mraccess77

In regard to your initial question about whether captions can be an alternative for 1.2.1, there was strong support from the AGWG on the draft response, and it has now been updated to be indicated as the Official response.

I thought there was a separate discussion where it was discussed that alternatives for SC 1.2.1 video only didn't not need to be visible - but alternatives for 1.2.1 audio-only did need to be visible. If the captions are not visible to anyone but provided, how would a person who is deaf or hard of hearing read them? It seems like this approach of an invisible caption track would fail the accessibility supported conformance requirement.

As you note, the discussion on whether a text alternative for audio-only content needs to be displayed on the page is a separate discussion. #3902 has been opened to tackle this separate topic.

If you feel other points touched on in this thread should result in new issues being opened to addressed, please open an issue. It's been an interesting discussion and I wouldn't want any additional points lost that need action from the Task Force.

As per our process, with the adoption of the response by the working group, I am marking this issue as Closed.

from wcag.