Re: Question on 1.2.4 and "publicly broadcast"

John raises good points.

This is a good area for debate. The line gets fuzzy between a video conference not needing this (per understanding) and a webcast of a performance needing this (in the examples in Understanding).

I agree with John that a tool that wanted to state: “host a WCAG 2.0 AA-conforming meeting or call using our tool” would need to enable this capability, even if every call made through that tool didn’t take advantage of the functionality.

We should probably clarify this understanding document. Someday.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com
http://twitter.com/awkawk

From: John Foliot <john.foliot@deque.com>
Date: Thursday, May 17, 2018 at 12:10
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Question on 1.2.4 and "publicly broadcast"
Resent-From: WCAG <w3c-wai-gl@w3.org>
Resent-Date: Thursday, May 17, 2018 at 12:08

Hi Laura,

This starts to get murky, as ultimately what I think you are asking is "...does the 'platform' need to support captioning..."? (To which I would suggest - yes)

When it comes to two individuals engaged in direct 1-1 video conversation however, whether or not the video requires 'captions' will be dependent on the scenario: for example, I could easily imagine a "video chat" window open (say even a conference call), where the deaf person would *also* have a separate TTY device included in the mix, circumventing the need for on-screen 'captions' as we traditionally know them.

None-the-less, I would suggest (however this is but my opinion) that the creators of video communications platforms (hardware or software or both) *SHOULD* have the capacity to support HTML5 style captioning solutions (the eco-system requirement), but that when it comes to individual content the decision is significantly more nuanced and I do not think it could be regulated as a black-or-white decision.

That said, content creators who seek to provide two-way communications via video chat will still shoulder the burden of ensuring that they are not discriminating against non-hearing users, so, for example, a "help-desk" application/solution that involved videos MUST support captions when required, or provide a functional equivalent. For large organizations, this is as much a policy concern as it is a technical one I suspect.

(Not sure if this answers the question, but hope this helps).

JF

On Thu, May 17, 2018 at 10:33 AM, Laura Carlson <laura.lee.carlson@gmail.com<mailto:laura.lee.carlson@gmail.com>> wrote:
Hello everyone,

I have received a question on 1.2.4 regarding if it is or id it isn't
applicable to content that is not "publicly broadcast" e.g. video
chat.

The understanding doc for 1.2.4 states [1], "This success criterion
was intended to apply to broadcast of synchronized media and is not
intended to require that two-way multimedia calls between two or more
individuals through web apps must be captioned regardless of the needs
of users."

If a person needs captioning in a private video chat does 1.2.4 apply?

Thank you.

Kindest Regards,
Laura

[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-real-time-captions.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FUNDERSTANDING-WCAG20%2Fmedia-equiv-real-time-captions.html&data=02%7C01%7Cakirkpat%40adobe.com%7Caa99568d3bb64975df8b08d5bc10afd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621702216665152&sdata=QeQAWcYAKsw530dffsBwQoqr%2B%2FZVl3ARUoWjka0YgXs%3D&reserved=0>

--
Laura L. Carlson



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion