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.
As a Working Group Note this content is stable, and the Working Group does not plan to make further changes. Should the need arise, however, the document could be updated. Comments received on this document will help the Working Group to decide if updates are needed, or will be taken into account should a republication be planned.
GitHub Issues are preferred for discussion of this specification.
Publication as a Working Group Note does not imply endorsement by theW3C 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.
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.
REQ 1d: Atomic pieces of data such as information regarding the person currently speaking, activities such as the people entering or leaving a meeting, or the last message posted in the chat channel, can be pinned to a user interface.
REQ 1e: For pinned content, there is a need to handle and support the metadata that allows the client engine to re-aggregate or re-route any pinned content.
REQ 1f: A user should have the ability to change the size of the window especially for sign language interpreters, certified deaf interpreters, and signing people.
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]
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.
4.3Accessibility user preferences and profiles
User Need 3: A user may need to change device or environment and have their accessibility user preferences preserved.
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. A deaf or hard of hearing user may also need to identify an incoming relay call.
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.
REQ 4c: Support the presentation and display of call prefix information for relay calls.
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.
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.
4.6Audio description in live conferencing
User Need 8: A user may struggle to hear audio description in a live teleconferencing situation.
REQ 8a: Ensure Audio Description (AD) recommended sound values are dynamic and have independent volume, EQ adjustment and routing capability.
REQ 8b: Support a users custom EQ profile.
REQ 8c: If not transmitted in a live screen share - ensure the platform doesn't strip captions or descriptions that may have been part of the original video.
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.
4.7Quality synchronisation and playback
User Need 9: Any 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.
4.8Simultaneous voice, text & signing
User Need 10: A deaf user needs to simultaneously talk on a call, send and receive real-time text and/or instant messages via a text interface and watch sign language using a video stream.
REQ 10a: Ensure support for multiple simultaneous streams.
User Need 14: In a teleconference a 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.
REQ 14b: Ensure participant metadata such as their name, their affiliation or other relevant information, is correctly associated with the meeting record and can be preserved for review after the call. This should be done with the participants consent.
4.13Captioning support
User Need 15: A deaf user or user with a cognitive disability needs to access a channel containing live transcriptions during a conference call or broadcast.
REQ 15a: Honor user preferences relating to captioned content. Provide support for signing or use of symbol sets e.g. Augmentative and Alternative Communication (AAC).
4.14Assistance for users with cognitive disabilities
User Need 16: Users with cognitive disabilities may need assistance when using audio or video communication.
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.
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.
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.
REQ 1d: Atomic pieces of data such as information regarding the person currently speaking, activities such as the people entering or leaving a meeting, or the last message posted in the chat channel, can be pinned to a user interface.
REQ 1e: For pinned content, there is a need to handle and support the metadata that allows the client engine to re-aggregate or re-route any pinned content.
REQ 1f: A user should have the ability to change the size of the window especially for sign language interpreters, certified deaf interpreters, and signing people.
Pause 'on record' captioning inRTC : 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.
The following is a list of updated requirements to existing user needs:
Incoming calls and caller ID - REQ 4c: Support the presentation and display of call prefix information for relay calls.
Routing and communication channel control - REQ 6a: Allow the separate routing of video streams such as, captioning or a sign language interpreter to a separate high resolution display.
Audio description in live conferencing - REQ 8b: Support a users custom EQ profile.
Audio description in live conferencing - REQ 8c: If not transmitted in a live screen share - ensure the platform doesn't strip captions or descriptions that may have been part of the original video.
Text and Video relay services (VRS) - REQ 12c: Ensure that privacy and security options are maintained when using relay services.
Call participants and status - REQ 14b: Ensure participant metadata such as their name, their affiliation or other relevant information, is correctly associated with the meeting record and can be preserved for review after the call. This should be done with the participants consent.
Captioning Support - REQ 15a: Honor user preferences relating to captioned content. Provide support for signing or use of symbol sets e.g. Augmentative and Alternative Communication (AAC).
Assistance for users with cognitive disabilities - REQ 16b: Provide support that is customised to the needs of the user. This may be via a relay service or speech-speech-relay-service.
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.