w3c / wai-media-guide

11 stars 41 forks source link

[!! important] Application of WCAG criteria in Checklists for Audio and Video and in WCAG Standard #121

Closed mmeller75 closed 4 years ago

mmeller75 commented 5 years ago

Checklists for Audio and Video include Captions (AA) for Live Audio-only. The tables in the WCAG Standard section include:

Is this correct? Reading the criteria, both 1.2.3 and 1.2.4 specifically reference synchronized media. Video-only and audio-only would not be synchronized "with another format for presenting information and/or with time-based interactive components", so these two SCs don't seem to apply. SC 1.2.9, which would include captions for live audio-only, is AAA.

Unless this resource is applying them as best practice. If so, can that be made more clear? Including descriptive audio for video-only is a great recommendation, but the way the tables are set up, it is implied that this is required.

shawna-slh commented 5 years ago

Thanks for the input @mmeller75 !

I'll ask AG folks to review this again.

Reviewers note:

alastc commented 5 years ago

The Time based media SC for 1.2.2 through to 1.2.7 are specific to 'synchronised media', which is generally synchronised audio & video, although it could be audio + text or video + text (or something else).

Only 1.2.1, 1.2.8 & 1.2.9 apply to video and/or audio only.

So if I'm understanding the aim of the checklists properly:

In the pre-recorded table under the "WCAG Standard" heading:

Pinging @bruce-usab as someone that knows the details of this better than I do for confirmation...

mmeller75 commented 5 years ago

@alastc In addition to what you listed above, as I understand it, the Live table under the "WCAG Standard" heading shouldn't list 1.2.4 in the Audio-only Captions cell.

bruce-usab commented 5 years ago

Thanks for looping me in. Is there a GitHub resource I might edit to show what I think the changes should be?

For example, at AAA, my understanding is that 1.2.9 Audio-only (Live) requires live streaming text, and that a static transcript in that case is not sufficient.

Another AAA example (1.2.8 Media Alternative (Prerecorded)) is that the checklist asserts, that for multimedia (a.k.a, video with speech or other meaningful audio), the “Transcript of audio information [can be] The same text from the captions file, in a different format.”

In my experience, this does not work! The CC timed text file will make use of the synchronization, and so might not identify that the person talking has changed. (Live captioning will indicate speaker changes with >> but even good CC might skip that if the speaker change is obvious from the onscreen visual action.) Also, CC will not repeat text that appears on screen (e.g., name placard of a speaker) and that sort of detail very much needs to in a transcript.

shawna-slh commented 5 years ago

Is there a GitHub resource I might edit to show what I think the changes should be?

Yes. This is the repo. Would be great to get your suggested edits. Thanks much!

Here is the page: https://github.com/w3c/wai-media-guide/blob/master/planning.md

You can fork, edit, and submit a pull request. (You can even see how your changes will look in the rendered page. Once you submit the pull request, several seconds later there will be a preview available -- as explained here.)

bruce-usab commented 5 years ago

Sorry to say I won’t get to this until early next week.

Do you prefer a single set of suggested edits (i.e., one pull request for all my changes) or should there be several pull requests, with one suggested change per pull request?

(I have no idea what pull requests look like on the owner’s side. Maybe this is a nonsensical question!)

shawna-slh commented 5 years ago

It's a good question. In this case, you can put them all in the same pull request -- will be easier to preview.

Highest priority is to get the standards requirements fixed in the tables and checklists.

I can take your input on the CC files needing more to be good transcripts and integrate it. So you don't need to write that if you don't want to.

bruce-usab commented 5 years ago

I finished editing my fork and submitted the pull request.

Resource implies that captions are provided for audio descriptions. That does happen sometimes, but the practice is counter-productive.

SC 1.2.5 does not apply to video-only media because it is not synchronized media.

SC 1.2.8 Media Alternative (Prerecorded) does not apply to audio-only media because it is not synchronized media.

Among other edits:

Edit 10/2: I am happy to provide line-by-line rational for my edits if that helps.

bruce-usab commented 5 years ago

@slhenry what is timeline for getting my edits incorporated (and/or debated)?

shawna-slh commented 5 years ago

HI Bruce. Thanks for the ping. I had missed your "I finished editing my fork" message.

I put this on my To Do list with HIGH priority. Possibly can get to it this week. For sure by early next week.

~Shawn

shawna-slh commented 4 years ago

Summary of changes:

Changes are shown in this pull request
and listed in the changelog.


Other change suggestions:

added “screenplay” wherever “descriptive transcript” appeared

I’d like to think about that some more, yet haven’t had the bandwidth. I created a separate issue for it.

changed “standards” to “requirements”

“Standards” is used based on input from usability testing with people who are not familiar with WCAG. If you feel strongly about this change, maybe most efficient if we chat briefly?

changed “description” to “audio description” most places

EOWG spent quite a bit of effort considering this and doing (informal) research on Terminology - Audio Description / Video Description / Described Video #75. I’d prefer not to re-open it.

changed inch mark / double prime to curly quotes because neutral quote marks are ugly and amateurish

I created a WAI-site-wide issue for it.


I think I caught everything. If I missed something, please open a new issue.

Thanks, all!

yatil commented 4 years ago

@bruce-usab

changed inch mark / double prime to curly quotes because neutral quote marks are ugly and amateurish

FWIW our Markdown parser already does that conversation, so the output should always have curly quotes (and other typographic symbols) even if the source text has none. (Many people are not used to typing them and it is quite hard to type them in certain operating systems.)