RTC Accessibility User Requirements – Call for Review

Accessible telecommunication technology is increasingly important for people who are working remotely and relying on real-time communication (RTC) for daily needs.

Web Real-time communications (WebRTC) is a series of protocols that support quick direct browser-to-browser transfer of call (and other data) without the need for a brittle plugin architecture. This transfer is nearly instantaneous with very small degrees of latency, and is considered a robust way of supporting peer-to-peer based communication. WebRTC technologies enable better video/audio calls, instant messaging text chat, file exchange, internet relay chat, screen sharing and more.

To make this happen the Internet Engineering Task Force (IETF) and W3C have collaborated since 2011 to standardize the necessary protocols and APIs, in particular the core WebRTC 1.0: Real-time Communication Between Browsers API specification. This spec defines a set of ECMAScript APIs that allow media to be sent to and received from another browser or device using an appropriate set of real-time protocols.

So what does this mean for the people with disabilities? How can people with disabilities effectively take advantage of the potential benefits that these real-time communication (RTC) protocols allow? What are the challenges for people with disabilities using RTC applications?

Challenges for People with disabilities using RTC applications

For real-time communication, video conferencing and instant messaging some of the challenges faced are; the need to route audio output to different sound cards or output devices, to support captioning and live transcription, and the transfer of alternate formats such as sign-language. The user may also need to be able to perform status polling (where on a call a user can query who is talking, or muted, on the call etc in a way that works with assistive technologies).

There are also different flavors of messaging preferred by blind users and Real-time text (RTT) needs for deaf and hard of hearing users.

Federal Communications Commission (FCC) and European requirements for Real-time text (RTT)

On December 15, 2016, the FCC adopted rules to facilitate a transition from text telephony (TTY) technology to Real-time text (RTT) technology.

TTY has been used by deaf and hard of hearing people to communicate over phone lines by text. TTY usage is declining. Now Real-time text allows the deaf and hard of hearing community to engage in more conversational style interactions that are critical for emergency services such as 911 and relay services such as 711. Real-time text has other advantages and is requirement in the European procurement standard EN 301 549 (PDF). It is therefore important that RTC applications support Real-time text.

RTC Accessibility User Requirements (RAUR) - First Public Working Draft published

Real-time communication applications have the potential to address these challenges but firstly designers and developers have to understand accessibility user needs. W3C/WAI is active in this space and in order to layout these challenges the Research Questions Task Force (RQTF) have published ‘RTC Accessibility User Requirements (RAUR)’ as a first public working draft.

The RQTF is a task force of the Accessible Platform Architectures (APA) working group at W3C. The APA works to ensure W3C specifications provide support for accessibility to people with disabilities.

RTC Accessibility User Requirements (RAUR) is designed to inform the reader of potential user needs for people with disabilities. It will also help initiate discussion and gather feedback on the best ways to address current gaps. The term RTC is used throughout to denote a range of technologies (including WebRTC) that when combined help to create accessible RTC applications.

From these user needs were drafted a set of user requirements that may be implemented at a system or platform level. Some may be authoring requirements.

Please note, in the context of this document we are outlining generic draft user requirements only. Those listed are not normative. This means they do not represent a series of things that you must do to conform to any current accessibility standard. This is a first public draft of what may go on to inform the development of other accessibility guidelines.

We welcome your feedback!

Your feedback will help inform our future work in both accessibility guidelines and technology specifications. We are therefore actively looking for your input on the development of these user needs and their related requirements.