Inconsistent SCs that use "media alternative" in Guideline 1.2

[bruce-usab]

There is inconsistent phrasing used within the SC of Guideline 1.2. This should be corrected.

SC 1.2.1, 1.2.2, and 1.2.3 all include the condition: “except when the media is a media alternative for text and is clearly labeled as such”.

This conditional is not used in other SC with similar structure (namely 1.2.5, 1.2.6, 1.2.7, and 1.2.8).

The conditional is not necessary (in the SC) because the normative definition for synchronized media already includes that qualification:

audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such

In other words, media alternatives for text are not synchronized media.

Proposal: For 2.2, we should remove the exception phrasing from 1.2.1, 1.2.2, and 1.2.3.

[alastc]

Hi Bruce,

That sounds logical (and thank you for tagging the issue appropriately). I do wonder though if it is right to rely on a definition to provide an important exception?

What doesn't seem logical (to me) to say that: This element on the page (e.g. a video with audio) is not syncronised media based on something else on the page.

I'd rather remove the exception from the defintion and add it to the SCs, unless there is some process reason that doesn't work? I know that is more verbose, it just seems odd to define syncronised media in that way.

[bruce-usab]

I agree that removing the exception from definition (and adding it to the SCs) is also a possibility.

I also agree that having an exception in definition is weird.

OTOH, the SC without the explicit exceptions are so much easier to read!

But I think that the readability is trumped by your observation about how illogical it is to have certain video with audio not be synchronized media based on something else on the page.

So, I agree with your fix.

(sorry i tried, but could not get the tag widgets to trigger correctly with the issue i created before this one. i got it figured this time around, obviously)

[alastc]

Hi Bruce,

I created a PR to make this update (pending approval) in #806.

When I got to "Sign Language (Prerecorded)" at AAA, I did wonder if we really want that condition at AAA?

Also, I tend to consider sign-language a translation, and even if there is equivelent text on the page it wouldn't be equivelent for someone who needs sign language. In which case, don't have the condition/exception at AAA?

What do you think?

If we don't apply the condition it's probably best done as a WCAG 2.2 thing as the requirements are tightening up. Otherwise just moving the condition from the definition to the SCs could be an errata (I think).

[mbgower]

I definitely think the exception should be called out in the understanding document (cross referenced to the definition), if it removed from the normative text.g

[bruce-usab]

Per call 7/14, i will review PR, especially as it impacts AAA SC.

[bruce-usab]

We discussed on call today, 4/13.

1. I don't believe ever took a pass at reviewing against 1.2.8 (see my 7/14 comment immediately above). Sorry!
2. As I understood the next steps, @alastc offered to write up an analysis, which will inform the exact edits required.
3. The consensus on the call was that, if there is a recommendation for an edit (quite probable), the PR should be formatted as an update to errata. Here are links to WCAG 2.0 errata and 2.1 errata.