W3C home > Mailing lists > Public > public-apa-admin@w3.org > October 2019

48-Hour Call for Consensus (CfC): WebRTC Accessibility Considerations

From: Janina Sajka (janina@rednote.net) <(janina@rednote.net)>
Date: Wed, 16 Oct 2019 11:15:51 -0400
To: Accessible Platform Architectures Administration <public-apa-admin@w3.org>
Message-ID: <20191016151551.GK2425@rednote.net>

This is a Call for Consensus (CfC) to the Accessible Platform
Architectures (APA) Working Group on a proposed Accessibility
Considerations addendum to the WebRTC 1.0 specification:


***Begin Proposed Section

Accessibility considerations [New section, informative]

The WebRTC 1.0 specification exposes an API to control protocols (defined
within the IETF) necessary to establish real-time audio, video and data

Real-time Text, defined in RFC 4103 on which people who are deaf or hard of
hearing (among others) rely on for their communication needs, utilizes T.140
encapsulated in RTP to enable the transition from TDD/TTY devices to IP-based
communications. Support for RFC 4103 is especially important as it is being
established as the new and more reliable mechanism for text communications
with Public Safety Access Points (PSAP).[1]

Since Real-time Text requires the ability to send and receive data in near
real time, it can be best supported via the WebRTC 1.0 data channel API. As
defined by the IETF, the data channel protocol utilizes the SCTP/DTLS/UDP
protocol stack, which supports both reliable and unreliable data channels. The
IETF chose to standardize SCTP/DTLS/UDP over proposals for an RTP data channel
which relied on SRTP key management and were focused on unreliable

Since the IETF chose a different approach than the RTP data channel as part of
the WebRTC suite of protocols, as of the time of this publication there is no
standardized way for the WebRTC APIs to directly support Real-time Text as
defined at IETF and implemented in U.S. (FCC) regulations.  The WebRTC working
Group will evaluate whether the developing IETF protocols in this space
warrant direct exposure in the browser APIs and is looking for input from the
relevant user communities on this potential gap.

Within the IETF MMUSIC WG, work is ongoing to enable Real-time text to be sent
over the WebRTC data channel, allowing gateways to be deployed to translate
between the SCTP data channel protocol and RFC 4103 Real-time text. This work,
once completed, would enable a unified and interoperable approach for
integrating real-time text in WebRTC user-agents (including browsers) -
through a gateway or otherwise.


At the time of this publication, gateways that enable effective RTT support in
WebRTC clients can be developed e.g. through a custom WebRTC data channel.

This is deemed sufficient until such time as future standardized gateways are
enabled via IETF protocols such as the SCTP data channel protocol and RFC 4103
Real-time text. This will need to be defined at IETF in conjunction with
related work in W3C groups to effectively and consistently standardise RTT
support internationally.

[1] https://www.ecfr.gov/cgi-bin/text-idx?SID=ada7cebd65433a9e05c35426a2bc76b8&mc=true&node=pt47.3.67&rgn=div5

***Action to Take***

This CfC is now open for objection, comment, as well as statements of
support via email. Silence will be interpreted as support, though
messages of support are certainly welcome.

If you object to this proposed action, or have comments concerning this
proposal, please respond by replying on list to this message no later
than 23:59 (Midnight) Boston Time, Sunday 20 October.

NOTE: This Call for Consensus is being conducted in accordance with the
APA Decision Policy published at:


Thanks especially to our Research Questions Task Force (RQTF)
for working with WebRTC to develop this addendum.



Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa
Received on Wednesday, 16 October 2019 15:15:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:22:54 UTC