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' in the context of this document and then goes on to list a range of these user needs and 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. Other documents may supersede
this document. 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 is an updated draft of RTC Accessibility User Requirements by the Accessible Platform Architectures Working Group. It is developed by the Research Questions Task Force (RQTF) who work to identify accessibility knowledge gaps and barriers in emerging and future web technologies. The requirements outlined here come from research into user needs that then provide the basis for any technical requirements. This version includes updates based on public feedback to the First Public Working Draft published 19 March 2020.
GitHub Issues are preferred for
discussion of this specification.
Publication as a Working Draft does not imply endorsement
by the W3C Membership.
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
1 August 2017 W3C Patent
Policy.
The group does not expect this document to become a W3C Recommendation.
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.
The traditional data exchange model is client to server. Real-time communication (RTC) is game-changing as it is enabled in part by specifications like WebRTC that provides real-time peer to peer audio, video and data exchange directly between supported user agents. This enables instantaneous applications for video and audio calls, text chat, file exchange, screen sharing and gaming, all without the need for browser plugins. However, WebRTC is not the sole specification with responsibility to enable accessible real-time communications, as use cases and requirements are broad - as outlined in the IETF RFC 7478 'Web Real-Time Communication Use Cases and Requirements' document. [ietf-rtc]
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 IG, Second Screen, and Web Audio Working group as well as AGWG and ARIA. 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 IETF Session Initiation Protocol RFC 5194 and the European Procurement Standard EN 301 549. [rtt-sip] [EN301-549]
3.1 Window anchoring and pinning
User Need 1: A deaf or hard of hearing user needs to anchor or pin certain windows in an RTC application so both a sign language interpreter and the person speaking (whose speech is being interpreted) are simultaneously visible.
REQ 1a: Provide the ability to anchor or pin specific windows so the user can associate the sign language interpreter with the correct speaker.
REQ 1b: Allow the use of flexible pinning of captions or other related content alternatives. This may be to second screen devices.
REQ 1c: Ensure the source of any captions, transcriptions or other alternatives is clear to the user, even when second screen devices are used.
3.2 Pause 'on record' captioning in RTC
User Need 2: A deaf or hard of hearing user may need captioning of content to be private in a meeting or presentation.
REQ 2a: Ensure there is a host operable toggle in the captioning service (whether human or automated) that facilitates going on and off record for the preserved transcript, but continues to provide captions meanwhile for 'off record' conversations.
REQ 2b: Ensure the toggle between saving recordings also applies to the saving of captions. There should be a mechanism that both audio and captions can be paused or stopped, and both can be simultaneously restored for recording.
3.3 Accessibility user preferences and profiles
User Need 3: A user may need to change device or environment and have their accessibility user preferences preserved.
REQ 3a: Ensure user profiles and accessibility preferences in RTC applications are mobile and can move with the user as they change device or environment.
3.4 Incoming calls and caller ID
User Need 4: A screen-reader user or user with a cognitive impairment needs to know a call is incoming and needs to recognise the ID of the caller.
REQ 4a: Provide indication of incoming calls in an unobtrusive way via a symbol set or other browser notification.
REQ 4b: Alert assistive technologies via relevant APIs.
3.5 Routing and communication channel control
User Need 5: A blind user of both screen reader and braille output devices simultaneously may need to manage audio and text output differently.
REQ 5a: Provide or support a range of browser level audio output options.
REQ 5b: Allow controlled routing of alerts and other browser output to a braille device or other hardware.
User Need 6: A deaf user needs to move parts of a live teleconference session (as separate streams) to one or more devices for greater control.
REQ 6a: Allow the separate routing of video streams such as, captioning or a sign language interpreter to a separate high resolution display.
User Need 7: Users with cognitive disabilities or blind users may have relative volume levels set as preferences that relate to importance, urgency or meaning.
REQ 7a: Allow the panning or setting of relative levels of different audio output.
REQ 7b: Support multichannel audio in the browser.
3.6 Dynamic audio description values in live conferencing
User Need 8: A user may struggle to hear audio description in a live teleconferencing situation.
User Need 9: Any deaf or hard of hearing user watching captioning or audio description needs to be confident it is synchronised and accurate.
REQ 9a: Ensure that any outages or loss to captioning or audio description will be repaired while preserving context and meaning.
REQ 9b: Ensure that the integrity of related alternate supporting tracks or streams such as transcriptions, are in sync with any repairs.
3.8 Simultaneous voice, text & signing
User Need 10: A deaf user needs to simultaneously talk on a call, send and receive instant messages via a text interface and watch sign language using a video stream.
REQ 10a: Ensure support for multiple simultaneous streams.
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 real-time text (RTT) in the same real-time session. [total-conversation]
3.9 Emergency calls: Support for Real-time text (RTT)
User Need 11: In an emergency situation a deaf, speech impaired, hard of hearing or deaf blind user needs to make an emergency call, instantly send and receive related text messages and/or sign via a video stream.
REQ 11a: Provide or ensure support for RTT in WebRTC.
REQ 11b: Avoid the problem of unsent emergency messages. A user may not be aware when they have not successfully sent an emergency message. For example, RTT avoids this problem due to instantaneous data transfer but this may be an issue for other messaging methods or platforms.
3.10 Video relay services (VRS) and remote interpretation (VRI)
User Need 12: A deaf, speech impaired, or hard of hearing user, needs to communicate on a call using a remote video interpretation service to access sign language and interpreter services.
REQ 12a: Provide or ensure support for video relay and remote interpretation services. This user need may relate to interoperability with third-party services; IETF has looked at standardizing a way to use Session Initiation Protocol (SIP) with VRS services. [ietf-relay]
REQ 12b: Provide support for other languages and translations. For example, VRS calls may be made between ASL (American Sign Language) users and hearing persons speaking either English or Spanish, or variations in signing itself such as Irish Sign Language (ISL which is related to French sign language) and British Sign Language (BSL). A user may need to stream or pin both.
3.11 Distinguishing sent and received text with RTT
User Need 13: A deaf or deaf blind user needs to tell the difference between incoming text and outgoing text.
REQ 13a: Ensure when used with RTT functionality, WebRTC handles the routing of this information to a format or output of the users choosing.
3.12 Call participants and status
User Need 14: In a teleconference a blind screen-reader user needs to know what participants are on the call, as well as their status.
REQ 14a: Ensure participant details such as name and status; whether the person is muted or talking is accessible to users of assistive technologies.
3.13 Live transcription and captioning support
User Need 15: A deaf user or user with a cognitive disability needs to access a channel containing live transcriptions or captioning during a conference call or broadcast.
REQ 15a: Honor user preferences relating to live transcription and captioning e.g. provide support for signing or a related symbol set.
3.14 Assistance for users with cognitive disabilities
User Need 16: Users with cognitive disabilities may need assistance when using audio or video communication.
REQ 16a: Ensure a WebRTC video call can host a technical or user support channel.
REQ 16b: Provide support that is customised to the needs of the user. This may be via a relay service.
3.15 Personalized symbol sets for users with cognitive disabilities
User Need 17: Users with cognitive disabilities may need to use symbol sets for identifying functions available in a WebRTC enabled client for voice, file or data transfer.
REQ 17a: Provide personalization support for symbols set replacements of existing user interface rendering of current functions or controls.
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 required by blind users
User Need 18: To translate text to speech interactions into comprehensible speech; a blind screen reader user depending on TTS to interact with their computers and smart devices needs a traditional Internet Relay Chat (IRC) style interface.
REQ 18a: Preserve IRC as a configuration option in user agents that implement WebRTC as opposed to having only the Real-time text (RTT) type interface. (RTT) is favoured by users who are deaf or hearing impaired. For screen reader users, TTS cannot reasonably translate text into comprehensible speech unless characters are transmitted in very close timing to one another. Typical gaps will result in stuttering and highly unintelligible speech output from the TTS engine.
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 text to speech (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.
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.
5.3 Bandwidth 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. Transmission aspects, such as frames per minute for video quality needs to be of high-quality.
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]
6. Data table mapping user needs with related specifications
The following table maps the user needs and requirements presented in this document with other related specifications such as those defined in RFC 5194 - Framework for Real-time text over IP Using SIP and EN 301 549 - the EU Procurement Standard. [rtt-sip] [EN301-549]
Overview of what specifications may address some of the use cases outlined above
Related specs or groups
Mapping to RFC 5194 - Framework for Real-time text over IP Using SIP:
Mapping to EN 301 549 - EU procurement standard
Incoming calls
WCAG/AGWG, ARIA.
Similar to 6.2.4.2 Alerting - RFC 5194/ pre-session set up with RTT 6.2.1
Under 'General Requirements for Text over IP (ToIP) '
No Mapping
Routing
Media Working Group, Web and Networks IG, Second Screen. Audio Device Client Proposal may fulfil this need and allow complex routing and management of multiple audio input and output devices.
No Mapping
No Mapping
Dynamic audio description values
Media Working Group, Web and Networks IG, Second Screen.
No Mapping
No Mapping
Audio-subtitling/spoken subtitles
Media Working Group, Web and Networks IG, Second Screen.
No Mapping
No Mapping
Communications control
Media Working Group, Web and Networks IG. Second Screen API may fulfil this user need. HTML5 supports exists and the streams need to be separable. Could be managed via a status bar.
Similar to R26 in 5.2.4. Presentation and User Requirements.
Similar to R26 in RFC 5194 5.2.4. Presentation and User Requirements. NOTE: Very similar user requirement to 'Audio Routing and Communication channel control'
No Mapping
Control relative volume and panning position for multiple audio
Web Audio Working Group. Multichannel may be covered by the Web Audio group space, and in audio device proposal, with some WebRTC requirements.
Similar to R26 in RFC 5194 5.2.4. Presentation and User Requirements. NOTE: Very similar user requirement to 'Audio Routing and Communication channel control'
No Mapping
Simultaneous voice, text & signing
Could be partially enabled via RTT in WebRTC.
Relates to RFC 5194 - under R2-R8
No Mapping
Support for video relay services (VRS) and remote interpretation (VRI)
May relate to interoperability with third-party services.
Relates to RFC 5194 - under R21-R23
No Mapping
Distinguishing sent and received text
May relate to interoperability with third-party services. This is not WebRTC specific and may be a user interface accessibility issue.
Relates to RFC 5194 - under R16 - but this does NOT fully address our use case requirement.
This is not WebRTC specific and may be a user interface accessibility issue.
Relates to RFC 5194 - under R14-R15
No Mapping
Quality of video resolution and frame rate
No Mapping
No Mapping
EN 301 549 Section 6, recommends WebRTC applications should support a frame rate of at least 20 frames per second.
Assistance for older users or users with cognitive disabilities
Needs further clarification/review may be an accessible user interface or personalization issue.
Relates to RFC 5149 - Transport Requirements/Text over IP (ToIP) and Relay Services.
No Mapping
Identify caller
WCAG/AGWG, ARIA. Needs further clarification/review may be an accessible user interface issue. Identity may be handled by the browser via Identity for WebRTC 1.0.
Similar to R27 in RFC 5194 5.2.4. Presentation and User Requirements
Browser APIs needed to implement this are available; needs better integration with third-party services (e.g. for sign language translation). Possibly covered by general requirements for Text over IP (ToIP) contained in RFC 5194.
Covered under 5.2.3 (transcoding service requirements). Referring to relay services that provide conversion from speech to text, or text to speech, to enable communication.
No Mapping
A. Change Log
The following is a list of new user needs in this document:
Window anchoring and pinning: A deaf or hard of hearing user needs to anchor or pin certain windows in an RTC application so both a sign language interpreter and the person speaking (whose speech is being interpreted) are simultaneously visible.
REQ 1a: Provide the ability to anchor or pin specific windows so the user can associate the sign language interpreter with the correct speaker.
REQ 1b: Allow the use of flexible pinning of captions or other related content alternatives. This may be to second screen devices.
REQ 1c: Ensure the source of any captions, transcriptions or other alternatives is clear to the user, even when second screen devices are used.
Pause 'on record' captioning in RTC: A deaf or hard of hearing user may need captioning of content to be private in a meeting or presentation.
REQ 2a: Ensure there is a host operable toggle in the captioning service (whether human or automated) that facilitates going on and off record for the preserved transcript, but continues to provide captions meanwhile for 'off record' conversations.
REQ 2b: Ensure the toggle between saving recordings also applies to the saving of captions. There should be a mechanism that both audio and captions can be paused or stopped, and both can be simultaneously restored for recording.
Accessibility user preferences and profiles: A user may need to change device or environment and have their accessibility user preferences preserved.
REQ 3a: Ensure user profiles and accessibility preferences in RTC applications are mobile and can move with the user as they change device or environment.
The following is a list of updated requirements to existing user needs:
Emergency calls and RTT - REQ 11b: Avoid the problem of unsent emergency messages. A user may not be aware when they have not successfully sent an emergency message. For example, RTT avoids this problem due to instantaneous data transfer but this may be an issue for other messaging methods or platforms.
Video relay services (VRS) and remote interpretation (VRI) - REQ 12b: Provide support for other languages and translations. For example, VRS calls may be made between ASL (American Sign Language) users and hearing persons speaking either English or Spanish, or variations in signing itself such as Irish Sign Language (ISL which is related to French sign language) and British Sign Language (BSL). A user may need to stream or pin both.
New note on personalization semantics and CSS media queries.
Moved 'User Need 19: 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' to the 'Quality of service issues' section.
Added note on ITU definition of Total Conversation services that relates to 'REQ 10a: Ensure support for multiple simultaneous streams'.
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 real-time text (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:
Judy Brewer, W3C
Michael Cooper, W3C
Dominique Hazael-Massieux, W3C
Scott Hollier, Edith Cowan University & Centre For Accessibility