RTC Accessibility User Requirements

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/apa/raur/
Latest published version:
https://www.w3.org/TR/raur/
Latest editor's draft:
https://w3c.github.io/apa/raur/
History:
https://www.w3.org/standards/history/raur
Commit history
Editors:
Joshue O'Connor (W3C)
Janina Sajka
(Educational Testing Service)
Michael Cooper (W3C)
Feedback:
GitHub w3c/apa (pull requests, new issue, open issues)

Abstract

This document outlines various accessibility related user needs, requirements and scenarios for real-time communication (RTC). These user needs should drive accessibility requirements in various related specifications and the overall architecture that enables it. It first introduces a definition of RTC as used throughout the document and outlines how RTC accessibility can support the needs of people with disabilities. It defines the term user needs as used throughout the document and then goes on to list a range of these user needs and their related requirements. Following that some quality related scenarios are outlined and finally a data table that maps the user needs contained in this document to related use case requirements found in other technical specifications.

This document is most explicitly not a collection of baseline requirements. It is also important to note that some of the requirements may be implemented at a system or platform level, and some may be authoring requirements.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Accessible Platform Architectures Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 2 November 2021 W3C Process Document.

Introduction

What is real-time communication (RTC)?

Real-time communication (RTC) is an evolution beyond the traditional data exchange model of client to server resulting in real-time peer to peer audio, video and data exchange directly between supported user agents. This allows instantaneous applications for video, text and audio calls, text chat, file exchange, screen sharing and gaming, all without the need for browser plug-ins. While real-time communication (RTC) applications are enabled in the main by specifications like WebRTC, WebRTC is not the sole specification with responsibility to enable accessible real-time communication applications. The use cases and requirements are broad - for example as outlined in the IETF RFC 7478 'Web Real-Time Communication Use Cases and Requirements' document. [ietf-rtc] [webrtc]

1. Real-time communication and accessibility

RTC has the potential to allow improved accessibility features that will support a broad range of user needs for people with a wide range of disabilities. These needs can be met through improved audio and video quality, audio routing, captioning, improved live transcription, transfer of alternate formats such as sign-language, text-messaging / chat, real time user support and status polling.

RTC accessibility is enabled by a combination of technologies and specifications such as those from the Media Working Group, Web and Networks Interest Group, Second Screen, and Web Audio Working group as well as AGWG and ARIA. The Accessible Platform Architectures Working Group (APA) hopes this document will inform how these groups meet various responsibilities for enabling accessible RTC, as well updating related use cases in various groups. For examples, view the current work on WebRTC Next Version Use Cases First Public Working Draft. [webrtc-use-cases]

2. User needs definition

This document outlines various accessibility related user needs for RTC accessibility. The term 'user needs' in this document relates to what people with various disabilities need to successfully use RTC applications. These needs may relate to having particular supports in an application, being able to complete tasks or access other functions. These user needs should drive accessibility requirements for RTC accessibility and its related architecture.

User needs are presented here with their related requirements; some in a range of scenarios (which can be thought of as similar to user stories).

3. User needs and requirements

The following outlines a range of user needs and requirements. The user needs have also been compared to existing use cases for real-time text (RTT) such as the IETF 'Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)' RFC 5194 and the European Procurement Standard EN 301 549. [rtt-sip] [EN301-549]

3.1 Window anchoring and pinning

Note

Not all atomic items necessarily are pinned next to other atomic elements but some may be dependent, related or updated synchronously. For example, if there are multiple atomic data points destined for an 80 character braille display that has been sectioned to display 4 atomic items in up to 19 spaces each (leaving at least one blank cell for spacing).

Note

Here the term atomic relates to small pieces of data. For the purposes of accessibility conformance testing, the definitions and use of the terms 'atomic' and 'atomic rules' may also be useful. [applicability-atomic] [rule-types]

3.2 Pause 'on record' captioning in RTC

3.3 Accessibility user preferences and profiles

3.4 Incoming calls and caller ID

Note

Successful design of operations required for acting on incoming calls, getting informed about who the caller is and connecting relay services should not require complicated sequences of user actions.

3.5 Routing and communication channel control

3.6 Audio description in live conferencing

Note

Moving beyond mono in this context is also important, as the stereo spread allows audio descriptions to be sound staged. Applications should also inherit customization settings from the user's operating system.

3.7 Quality synchronisation and playback

3.8 Simultaneous voice, text & signing

Note

This user need may also indicate necessary support for 'Total conversation' services as defined by ITU in WebRTC applications. These are combinations of voice, video, and RTT in the same real-time session. [total-conversation]

3.9 Emergency calls: Support for Real-Time Text (RTT)

3.10 Text and Video relay services (VRS)

Note

To successfully connect video or text relay services should not require a complicated sequence of user actions.

3.11 Distinguishing sent and received text with RTT

3.12 Call participants and status

3.13 Captioning support

3.14 Assistance for users with cognitive disabilities

3.15 Personalized symbol sets for users with cognitive disabilities

Note

This relates to cognitive accessibility requirements. For related work at W3C see the 'Personalization Semantics Content Module 1.0' and 'Media Queries Level 5'. [personalization] [media-queries]

3.16 Internet relay chat (IRC) style interfaces

Note

Some braille users will also prefer the RTT model. However, braille users desiring text displayed with standard contracted braille might better be served in the manner users relying on TTS engines are served, by buffering the data to be transmitted until an end of line character is reached.

4. Relationship between RTC and XR Accessibility

There are potential real-time communication application issues that may only apply in immersive environments or augmented reality contexts.

For example, if an RTC application is also an XR application then relevant XR accessibility requirements should be addressed as well. [xaur]

5. Quality of service scenarios

5.1 Deaf users: Video resolution and frame rates

Scenario: A deaf user watching a signed broadcast needs a high-quality frame rate to maintain legibility and clarity in order to understand what is being signed.

Note

EN 301 549 Section 6, recommends WebRTC applications should support a frame rate of at least 20 frames per second (FPS). More details can be found at Accessible Procurement standard for ICT products and services EN 301 549 (PDF) and ITU-T Series H Supplement 1 "Sign language and lip-reading real-time conversation using low bit-rate video communication".

5.2 Audio frequency bandwidth

Scenario: A hard of hearing user needs better stereo sound to have a quality experience in work calls or meetings with friends or family. Transmission aspects, such as decibel range for audio needs to be of high-quality. For calls, industry allows higher audio resolution but still mostly in mono only.

Note

EN 301 549 Section 6, recommends for WebRTC enabled conferencing and communication the application shall be able to encode and decode communication with a frequency range with an upper limit of at least 7KHz. More details can be found at Accessible Procurement standard for ICT products and services EN 301 549 (PDF)

6. Quality requirements for video

Scenario: A hard of hearing user needs better stereo sound so they can have a quality experience in watching HD video or having a HD meeting with friends or family. Similarly for video quality, transmission aspects such as frames per second needs to be of high-quality.

Note

A hard of hearing user often combines their perception of speech from audio with their perception of lip movement and other visual clues to create an overall understanding of speech. For the visual parts, the requirements on video are the same as expressed in '5.1 Deaf users: Video resolution and frame rates' about perception of sign language because lip movements are also part of sign language, equally rapid and as detailed as the other parts of sign language.

Note

EN 301 549 Section 6, recommends for WebRTC enabled conferencing and communication the application shall be able to encode and decode communication with a frequency range with an upper limit of at least 7KHz. More details can be found at Accessible Procurement standard for ICT products and services EN 301 549 (PDF)

Note

WebRTC lets applications prioritise bandwidth dedicated to audio / video / data streams; there is also some experimental work in signalling these needs to the network layer as well as support for prioritising frame rate over resolution in case of congestion. [webrtc-priority]

A. Change Log

The following is a list of new user needs and requirements since the publication of the previous working draft:

The following is a list of updated requirements to existing user needs:

The following are other changes in this document:

Note

This user need may also indicate necessary support for 'Total conversation' services as defined by ITU in WebRTC applications. These are combinations of voice, video, and RTT in the same real-time session. [total-conversation]

This document has been updated based on document feedback, discussion and Research Questions Task Force consensus.

B. Acknowledgments

B.1 Participants of the APA working group active in the development of this document:

B.2 Previously Active Participants, Commenters, and Other Contributors

C. Enabling funders

This work is supported by the EC-funded WAI-Guide Project.

D. References

D.1 Informative references

[applicability-atomic]
Accessibility Conformance Testing (ACT) Rules Format 1.0 - W3C Recommendation, 31 October 2019. Wilco Fiers; Maureen Kraft; Mary Jo Mueller ; Shadi Abou-Zahra. W3C. 2019. URL: https://www.w3.org/TR/act-rules-format/#applicability-atomic
[EN301-549]
Accessibility requirements for ICT products and services. CEN/CENELEC/ETSI. March 2021. URL: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
[ietf-relay]
Interoperability Profile for Relay User Equipment. IETF. August 2020. URL: https://tools.ietf.org/html/draft-ietf-rum-rue-02.html
[ietf-rtc]
Web Real-Time Communication Use Cases and Requirements. IETF. March 2015. URL: https://tools.ietf.org/html/rfc7478
[media-queries]
Media Queries Level 5. W3C. 31 July 2020. URL: https://www.w3.org/TR/mediaqueries-5/
[personalization]
Personalization Semantics Content Module 1.0. W3C. 27 January 2020. URL: https://www.w3.org/TR/personalization-semantics-content-1.0/
[rtt-sip]
Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). IETF, Network Working Group. June 2008. URL: https://tools.ietf.org/html/rfc5194
[rule-types]
Accessibility Conformance Testing (ACT) Rules Format 1.0 - W3C Recommendation, 31 October 2019. Wilco Fiers; Maureen Kraft; Mary Jo Mueller ; Shadi Abou-Zahra. W3C. 2019. URL: https://www.w3.org/TR/act-rules-format/#rule-types
[total-conversation]
ITU-T SG 16 Work on Accessibility - Total Conversation. International Telecommunication Union (ITU). 2020. URL: https://www.itu.int/en/ITU-T/studygroups/com16/accessibility/Pages/conversation.aspx
[webrtc]
WebRTC 1.0: Real-Time Communication Between Browsers. W3C. 26 January 2021. URL: https://www.w3.org/TR/webrtc/
[webrtc-priority]
WebRTC DSCP Control API. W3C. 12 February 2020. URL: https://w3c.github.io/webrtc-priority/
[webrtc-use-cases]
WebRTC Next Version Use Cases. W3C. 11 December 2018. URL: https://www.w3.org/TR/webrtc-nv-use-cases/
[xaur]
XR Accessibility User Requirements. W3C. 16 Sept 2020. URL: https://www.w3.org/TR/xaur/