Real-time communication access (video/audio)

[dansommer]

Hi there!

The SC 1.2.x concerning time-based media cover in great detail how to make prerecorded media and live broadcasts accessible to users through transcription, closed captions, audio description, and sign language.

I'm not able to find any information or guidance on communication access between two or more people on different devices in real-time settings through video or audio (video conferencing).

I'm not sure if video conferencing software like Zoom, Teams, etc. is within the purview of WCAG, but with technical documentation of WebRTC being drafted, I was curious if there are plans to make real-time communication access (through transcription, captions, sign language, interpretation/audio description/secondary audio track) part of the WebRTC infrastructure and expand WCAG documentation to include guidance and Success Criteria.

https://w3c.github.io/webrtc-pc/

This is my first time posting. Looking forward to your response. Thank you. Dan

[patrickhlauke]

interestingly, SC 1.2.4: Captions (Live) (Level AA) explicitly exempts "two-way multimedia calls" - likely under the assumption at the time that they'd be using a non-web system/3rd party software.

however, i'd argue that that exemption (only present in the understanding document, so not normative per se) is a bit long in the tooth, and doesn't consider whether or not captions are available (rather than whether or not callers/hosts are actually enabling them, which is a different matter altogether). in my view, i'd definitely ding a site/web application that provides "two-way multimedia calls" but does not offer at least the option to enable captions, and does not offer an equivalent alternative (using text-based chat or similar)

[dansommer]

Thanks for those insights.

It certainly makes sense that those exemptions would be put in place if web applications didn't easily allow for two-way multimedia calls or if such communication could only happen through non-web system and 3rd-party software. That would seem appropriate given the time the documentation was created.

Since W3C is now providing (or at the very least drafting) technical guidance for real-time communication for two or more parties through the web-based WebRTC protocols, would it be helpful for there to be accessibility guidelines and guidance documentation for this type of online video streaming included in WCAG?

https://w3c.github.io/webrtc-pc/

[patrickhlauke]

as a first step, i'd suggest proposing that the understanding for things like SC 1.2.4 is updated to NOT imply that those scenarios aren't covered. beyond that, I think other aspects of a two-way communication should already be reasonably covered by existing SCs already.

[dansommer]

Thank you. Understood. However, considering that visual language to spoken or written language isn't included in WCAG for prerecorded media, as pointed out by the post below, it doesn't seem a fair statement that "other aspects of a two-way communication should already be reasonably covered by existing SCs already."

#1910

Reasonable accommodations to sign-language only videos might include text-translation or voice-overs. The suggestion that sign-language videos are only intended for those who sign is reasonable for pre-recorded media but doesn't reasonable when it comes to two-way communication. I'm finding it difficult to understand how the SCs lead to equal access in these situations.

[patrickhlauke]

Reasonable accommodations to sign-language only videos might include text-translation or voice-overs.

in the context of a live two-way communication, that will be exceedingly difficult

[dansommer]

Thank you but I would respectfully disagree. CART and SLI providers facilitate this type of communication on a daily basis. If W3C is drafting technical documentation for WebRTC which enables two-way communication (or more participants), why is there not WCAG documentation which covers this in-browser technology?

Perhaps I'm unclear about the purpose of WCAG.

Is WCAG there to ensure that the applications which power the web provide the possibility for content to be accessible or it is to ensure that the content producers is accessible? For example, is WCAG's purpose that YouTube provide its users with the options to upload and provide access to content that meet WCAG 2.1 Criteria? Or is saying that video content producers should provide closed captions and that is' content producers responsibility to meet the SC outlined in WCAG?

[patrickhlauke]

Thank you but I would respectfully disagree. CART and SLI providers facilitate this type of communication on a daily basis.

for two-way communication, e.g. one person video-calling another person, and they both have CART and SLI?

[patrickhlauke]

Perhaps I'm unclear about the purpose of WCAG.

perhaps you're also unclear about how WCAG is produced...by a series of, mostly, volunteers from various bodies, organisations, and in their own private capacity, trying to come up with reasonable baseline recommendations. if you have suggestions for any gaps in WCAG, and how they could/should be filled, feel free to submit a suggestion and start the conversation.

as for the question about where the responsibility for meeting SCs lies ... for third-party/user generated content, it's obviously a shared responsibility of the system providing capabilities to add things like captions, and then the producer/user's responsibility to actually take advantage of that capability and provide it

[dansommer]

My ignorance is great and I appreciate you filling in the gaps. For the past two years I've been trying to connect with accessibility specialists and gain understanding of their perspectives. The greatest gap seems to be between an application enabling an accessibility service and the content producers including those services. It's great that this shared responsibility is clear to you, but that is not so obvious to the producers of content.

If YouTube enables its users to upload closed captions on all its videos, that doesn't mean all users will upload accurate closed captions which meet the minimum standards of equal access. Is YouTube accessible because it enables users to meet WCAG 1.2.2 requirements or is it not compliant because it doesn't require all its members to meet those requirements?

The demands of live captioning as outlined in WCAG 2.1 have been entirely one-way (no need for any two-way communication, be it audio, visual, or textual communication) and they are no longer complete or appropriate for the two-way communication W3C is facilitating through WebRTC. The existing SC don't seem sufficient for the demands of real-time communication.

[dansommer]

if you have suggestions for any gaps in WCAG, and how they could/should be filled, feel free to submit a suggestion and start the conversation.

I appreciate the guidance. It would seem that my desire to have a general discussion about communication access is not in line with practices of this forum and that it's necessary to provide comments and suggestions for specific update to the WCAG documentation and start a general discussion about accessibility topics which are not clearly defined in WCAG.

I think my confusion stemmed from this thread which dismissed the legitimate need for equal access and proposed that sign-language only videos are intended only for people who sign and providing a textual or verbal equivalent was not required even though equal access to these videos was not provided. Would it be fair to say that videos with spoken audio are intended only for people who have the ability to comprehend that medium of communication?

#1910

If WCAG does not consider the need to translate prerecorded videos with visual language into written or spoken language, it would seem understandable that it doesn't see the need to identify or provide guidance for equal access in two-way real-time communication.