1.2.3 / 1.2.5 Audio description - right language required?

[detlevhfischer]

As far as I can see, neither the normative text of 1.2.3 and 1.2.5 nor the definition of "audio description" has anything on the 'right' language for such description (maybe due to an english-centric bias where AD in different languages rarely surfaces). In a current audit of a German site, there are videos with a voice-over comment in English describing what happens.

Looking strictly at the normative text we'd have to pass this provided the AD covers the visuals sufficiently - even if the AD language were Chinese (and we'd be able to tell whether it covers the visuals, which we aren't) - right?

Since there is no markup for spoken language, 3.1.2 Language of parts would not really help here.

Or am I missing something?

[mbgower]

Proposed draft response 1

As far as I can see, neither the normative text of 1.2.3 and 1.2.5 nor the definition of "audio description" has anything on the 'right' language for such description

You are correct. There is no wording in any of the 1.2 Time-based Media which makes an explicit statement that the alternative provided is in the same language as the original (with the possible exception of the language in 1.2.1 which uses the phrase "presents equivalent information").

This shortcoming is most apparent in situations where translation of time-based media content exists, in the form of subtitles.
If a video has English dialog and has Spanish subtitles, the subtitles would seem to qualify as captions, which are defined as:

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content

However, anyone who speaks English but not Spanish, who is in need of captions, will not consider Spanish 'captions' to meet their need, in the above situation. Likewise, in the situation where the video was dubbed in Spanish but the captions were presented in English, a deaf Spanish-only speaker would similarly feel the captions were not meeting their need.

---

[JUNE 2nd UPDATED, AFTER DISCUSSION IN TASK FORCE MEETING, WE BELIEVE THE FOLLOWING SHOULD BE CHANGE. See details in later comment.]

Looking strictly at the normative text we'd have to pass this provided the AD covers the visuals sufficiently

Given this limitation has existed in WCAG language for 15 years, it may be unnecessary to make a normative change to the 2.x wording; there is a clear expectation of matching the language of text alternatives of any kind with the existing language on the page. In your situation, if the language of the page is German, but the audio descriptions of a video on the page are in English, this expectation of consistent language seems reasonable grounds for challenging the use of English in a German-language video. There is also the question of whether Language of Parts has been done properly.

---

The problem with the existing lack of clarify around text alternatives matching the language of the original content has been added to the WCAG 3 parking lot under the section Assumption of matching language/dialect is not explicit

[detlevhfischer]

Thanks, @mbgower. I think the gap is clear and the need for the right language of AD evident.
I was just trying to frame it in terms of the practical problem of how to deal with it in a PASS/FAIL audit.

I was saying that "we'd have to pass this provided the AD covers the visuals sufficiently".

When you replied, "You are correct", are you saying we must pass this since there is no normative language to FAIL it?
Or do you say, "everyone knows that right language is implied, so we should FAIL this even in the absence of normative text supporting that?" Which of the two is it?

Whichever way this goes, I'd really like to get a WG consensus on this since this situation is not infrequent.
For cases of alt in the wrong language, we can at least resort to 2.4.4 (links) or 2.4.6 (button labels) and say "this is not descriptive" (for the intended audience). But bringing AD under 2.4.6 would surely be a stretch.

[patrickhlauke]

Agree that there is an unspoken assumption in the SCs (and even in 1.1.1 when it comes to text alternatives) that of course nobody would be so silly as to provide the alternatives/descriptions/etc in a completely different language from the surrounding content (not necessarily the page as a whole, but at least its immediate vicinity/context). While adding a requirement along those lines can't be done in non-normative documents (otherwise it would, quite rightly, be called out as adding new normative requirements by the backdoor), it would be good to at least strongly suggest that this should be done, but that it technically passes the tightly defined wording of the SC

[melaniephilipp]

Does the requirement that a conforming alternate version "provides all of the same information and functionality in the same human language..." give you the normative cover you are looking for?

[patrickhlauke]

The thing with the conforming alternate version is that, on its face, that term is used when talking about content that does not satisfy an SC on its face per https://www.w3.org/TR/WCAG22/#cc1 (i.e. the content itself wouldn't pass an SC, but there is an alternate version of the content/page that provides the content in a conformant way), whereas here the alternatives are part of the SC's requirement itself (and they don't link to that definition of conforming alternate version). So again, while the idea seems to implicitly be there, it wasn't made explicit in the way the normative stuff was put together?

[dabrams888]

of course nobody would be so silly as to provide the alternatives/descriptions/etc in a completely different language

I ran into this silly scenario the other day, though it wasn't as straight-forward as you may think. In testing a video that had both English and Spanish dialog in the audio track, I wasn't sure what the best recommendation would be for the language of captions and transcripts.

Option 1

The captions/transcripts keep a consistent language throughout and provide a separate version for each language (including indications when the spoken language changes).

This seems more like a "subtitle" than a "caption".

Option 2

The captions/transcripts match the exact text that was spoken regardless of language since that's more "equivalent" to the audio.

Practically speaking, option 1 sounds better. But option 2 seems like the more "conformant" option since it's an exact alternative to the spoken audio.

I know this thread is focused more on AD, but it seems like this topic extends pretty well to captions and transcripts too.

[mbgower]

I think @melaniephilipp's point about conforming alternate version is worth exploring, particularly note 3:

If multiple language versions are available, then conforming alternate versions are required for each language offered.

That seems to potentially give us some scope to address the existing normative language of all the different use cases cited on this page.

It does not resolve exactly what would pass and fail -- at least I don't think we'd arrive at consensus. However, it would seem to offer an auditor sufficient technical wording to question the use of a different language in an 'equivalent' or 'alternative' version than the language of the originating page/parts.

[detlevhfischer]

As it stands, the proposed WG answer does not clarify my question, which was focused on whether the use of the wrong language in AD is a normative fail. So I think either the WG answer should clarify that technically speaking, it is not (as @patrickhlauke seems to suggest above) or this needs more time to develop an argument that finds normative backing for a FAIL elsewhere. I am fine with it either way, but what to get out of the grey zone.

[guyhickling]

Language mismatches don’t just happen in video captions and (as Patrick points out above) SC1.1.1 alternative texts). It also occurs in a variety of other kinds of content mark-up where two or more languages are involved, on bi-lingual websites.

The problem concerns everything in these foreign language translations, including aria-label attributes, alt texts, texts hidden by CSS for screen readers, aria-roledescription attributes, the <title> element in the section, and a few other things. These are far more common than captions in the wrong language (in fact I’ve never seen that in captions myself, though I can imagine someone would do it and then claim compliance), and I’ve been thinking about them for a while. For instance, I frequently have to audit Welsh page translations created for public sector organisations and agencies in the UK, and I almost never see these screen reader items translated. Which is not good for users who are not fluent in the original language.

So I have raised a separate GitHub issue for that, as I think those screen-reader things would need one SC, and this matter of captions and audio descriptions (and transcriptions as well) should have a separate SC. I do advocate for having a new SC for this, and I don’t think this captions/audio descriptions problem should have to wait for WCAG3 either.

[mbgower]

Proposed Draft Response Alteration

Although individual criteria do not explicitly state that text alternatives and equivalents match the language of the page, the overall Conformance sections of the specification do.

5.2.4 requires that "Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria...". The definition of "accessibility supported" states explicitly that "...the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content."

In addition to this explicit need to make accessibility supported content match the language on a conforming page, 5.2.1 states that where an author chooses instead to offer a conforming alternate version, it "...provides all of the same information and functionality in the same human language... and if multiple language versions are available, then conforming alternate versions are required for each language offered."

5.2.2 Full Pages states "Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded."

In the Success Criteria themselves, "human language" is made explicit in 3.1.1 Language of the Page which requires that "The default human language of each Web page can be programmatically determined."

In short, WCAG is predicated on the assumption that a page's content is in a consistent default language, including text alternatives and equivalents. If the page's content deviates from this default human language, WCAG requires, in 3.1.2 Language of Parts, that that be captured programmatically so it can be conveyed to assistive technologies and thus to the user.

Looking at the list of criteria below, it is clear that if the alternative was offered in a human language other than the language of the content, the alternatives intended to make the content for accessible would be valueless to those who could not understand the altered human language.

• 1.1.1 Non-text Content: "...text alternative that serves the equivalent purpose..."
• [from definition of text alternative] "...Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content..."
• all the criteria under 1.2 Time-Based Media
• 1.3.1 Info & Relationships: "...can be programmatically determined or are available in text."
• 1.4.5 Images of Text: "...text is used to convey information rather than images of text..."
• 2.4.2 Page Titled: "Web pages have titles that describe topic or purpose."
• 2.4.4 Link Purpose (In Context): "The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context..."
• 2.4.6 Headings and Labels: "Headings and labels describe topic or purpose."
• 2.5.3 Label in Name: "...the name contains the text that is presented visually."
• 3.3.1 Error Identification: "...the item that is in error is identified and the error is described to the user in text."
• 3.3.2 Labels or Instructions: "Labels or instructions are provided when content requires user input."
• 3.3.3 Error Suggestion: "...suggestions are provided to the user..."
• 3.3.5 Help: "Context-sensitive help is available."

The Working Group will undertake to add notes to understanding documents to state that text alternatives and equivalents should match the human language of the original content (normally the default human language for the page).

[gundulaniemann]

I fully agree with the last sentences. Do we already have github issues for that, or some other measure this point does not get lost?

[alastc]

Worth getting agreement on this approach before starting that work, we can hang them off this issue.

[mbgower]

@gundulaniemann

Do we already have github issues for that, or some other measure this point does not get lost?

This issue will be discussed on tomorow's AGWG call. If we get support coalescing around the second draft response, we can then proceed to create PRs to resolve this issue (it would not be labelled "response only", if the second draft got support).

[detlevhfischer]

I read yesterday's call minutes and the resolution for this issue.
To be honest, I would not have raised it had I known that it (and the changes that will consequently be made to understanding texts) would take up so much time.

One thing would be important to clarify in those additions regarding the use of the correct language.

There are cases where a page in one language (say, German) contains a self-contained element in another language (say, English), for example, a video showing some activity with a running English commentary that may not cover some of the visual information, thus requiring an additional audio description. This AD could be in English (matching the language of the self-contained content element) or it could be in German (matching the language of the page). I think the addition should be clear about this situation - in the case sketched, personally I would find both approaches defensible and would not call either of them a FAIL of 1.2.3/1.2.5.

The situation is clearly different for alt text, (hidden) element labels, error message language, etc., where the agreed addition to understanding texts would clarify that the language of those needs to match that of the page content (and failing to do so would likely cause a FAIL in 2.4.6 or 2.4.4).