*developed with a consensus by deaf, hard of hearing, and DeafBlind consumer advocacy organizations and subject matter experts
Different applications have different features and approaches to accessibility. Entities must evaluate accessibility in consultation with deaf or hard of hearing users when choosing video-conferencing platforms. They also may need to consider the security of each respective video-conferencing platform. Security and accessibility can be (but need not be) in tension, and entities are encouraged to pick the most accessible platform that meets the organization’s security requirements.
This document does not evaluate the security of platforms, and entities should consult other resources to understand the security implications of their choices.
The feature matrix is current as of May 1, 2020. Note that video-conferencing software constantly evolves. Entities and deaf or hard of hearing users should double-check presence and absence of needed features prior to making a final determination. The platforms in the feature matrix below were tested on the respective supported device categories (desktop and mobile). The section below this feature matrix provides some details and tips on how to test for needed features.
Some of the features that employers may want to consider are:
- Integration with captioning services (e.g. remote CART and StreamText)
- User-customized appearance and font size of captions
- Integration with automatic speech recognition (ASR) services
- Availability of ten-digit numbers to allow participation via relay services
- Pinning of videos to support sign language interpreters when video follows the active speaker
- Participant-controlled resizing of video to improve visual access to interpreters and/or lip-reading
- Availability of enlarged videos and screen-sharing at the same time to support interpreting and/or lip-reading in presentation mode
- Text-chat functionality with prominent visual notifications
- Number of videos supported without degradation of quality
- Support for video gallery view
- Support for co-host or moderator roles
Tips for Evaluating a Platform’s Features
Each feature of a platform can be checked or tested independently. Generally, such tests should actively involve the deaf or hard of hearing participants, as they may notice issues specific to their needs that could be missed by hearing people. The tests also need to involve such participants in their respective roles (host, moderator, or participant), as on some platforms the views of hosts, moderator and participants without special privileges can be radically different.
- CART or StreamText integration: Schedule a technology testing session prior to the meeting with the chosen captioning vendor. The captioner may need to join as a participant and then be assigned the captioner role by the host.
- Turn on/off customize captions: If the platform offers ASR captions, test customization as a participant with an active speaker with ASR captions enabled. Else, test customization during the technology test with the captioning vendor as per the previous point.
- ASR integration: Set up a test meeting with a variety of speakers (gender, race, nationality) that mirror the diversity expected during typical workplace meetings. Have the speakers take turns. Have a hearing person as a participant monitor the caption accuracy and latency. In parallel, have a deaf or hard of hearing person as a participant evaluate the ASR captions for usability and ability to follow the meeting with multiple speakers.
- Relay Service integration via phone number: Set up a test meeting with a call-in number. Have a deaf or hard of hearing person as a participant connect to the meeting via a computer, and in parallel make a phone call through their relay provider. Evaluate the ability of the participant to have a conversation with multiple speakers taking turns.
- Pin sign language interpreter video when video follows voice: Set up a test meeting where video follows voice, with at least three people, two of whom should use spoken language. Have one person speak, and evaluate the ability of the deaf or hard of hearing person as a participant to select and enlarge a different video from the active speaker, also different from their own video stream. If the platform supports a spotlighting-type of feature, repeat this test with the host or moderator selecting and spotlighting a different video from the active speaker.
- Participant can enlarge or pin videos: Set up a test meeting with at least as many people as are typically expected to be on video at the same time. With all videos active, have the deaf or hard of hearing person as a participant select a video and attempt to enlarge it; then switch among multiple active speakers on video and verify that the video stays enlarged even when speakers switch, and that the chosen enlarged video can easily be changed.
- Participant can see screen share and enlarged video: This is a feature where host and participant views can differ, and where it is especially important to test out both views. Set up a test meeting with at least three people on video. Have the host start with screen sharing, and verify that the deaf or hard of hearing person as a participant can comfortably view the host’s video. Then switch screen sharing to the second person in the meeting (other than the host or deaf or hard of hearing person). Re-check if the deaf or hard of hearing person can comfortably view the second person’s video. Then assign screen sharing to the deaf or hard of hearing person, and have them verify that they can still comfortably view other people’s videos; this is intended to cover the scenario where the deaf or hard of hearing person is a presenter.
- Has text chat and prominent visual text notices: Set up a test meeting with at least four people on video. Have a person type something on text chat. The deaf or hard of hearing person should evaluate with the text chat box closed (or in the default configuration presented when the meeting starts) whether the text notification easily catches their attention. Further, they should verify that when they open the text chat, the chat does not block important parts of the video.
- Number of videos at the same time with good quality: Set up a test meeting with at least as many people as are typically expected to be on video at the same time.
- If the deaf or hard of hearing person uses sign language, at least one person other than this person should know sign language for this test. With all videos active, have that other person sign and have the deaf or hard of hearing person evaluate whether the resolution and frame rate are good enough for comfortably understanding sign language (typical targets are 30 frames per second and at least 640×480 video, but individual requirements may differ). If the video quality is marginal, and the meeting platform offers a spotlighting-type of feature, repeat the test with the active signer spotlighted.
- If the deaf or hard of hearing person listens and lip-reads, with all videos active, have a person speak, and the deaf or hard of hearing person evaluate whether the resolution and frame rate comfortably support lip-reading.
- Gallery View: Set up a test meeting with at least as many people as are typically expected to be on video at the same time. Evaluate whether all videos can be made visible to a person in the participant role on the screen at the same time. If the participant must scroll among videos, this requirement is not being met.
- Co-Hosting: Set up a test meeting with the number of desired co-hosts/moderators, plus at least one more regular participant. Evaluate whether all co-hosts and moderators are able to take the desired actions for running an accessible meeting, such as muting participants, pinning or spotlighting videos, managing hand raising and so on; and that the participant is able to observe the effect of these actions.
This guide was developed by deaf and hard of hearing consumer advocacy organizations and subject matter experts:
- American Association of the DeafBlind*
- Association of Late-Deafened Adults (ALDA)*
- Cerebral Palsy and Deaf Organization (CPADO)*
- Deaf in Government (DIG)
- Gallaudet University
- Gallaudet University Technology Access Program/Deaf Hard of Hearing Technology RERC
- Hearing Loss Association of America (HLAA)*
- National Association of the Deaf (NAD)*
- National Association of State Agencies of the Deaf and Hard of Hearing (NASADHH)
- National Technical Institute for the Deaf (NTID) Center on Employment
- Samuelson-Glushko Technology Law & Policy Clinic at Colorado Law(counsel to TDI)
- Telecommunications for the Deaf and Hard of Hearing, Inc. (TDI)*
- Tina Childress, Deaf assistive technology expert
 Captions overlaid on the video, if done well, reduce split visual attention.
 Some video conferencing systems have hard-to-read caption defaults.
 Integrated ASR that feeds off the conference audio tends to provide better accuracy and usability than ASR that runs on a separate system.
 Video Relay Services and IP Captioned Telephone Services can connect only if a phone number is available.
 If the video follows the speaker, the participant loses access to the interpreter; conversely, a signing participant may want to keep the video on themselves rather than on the interpreter providing the translation into spoken language.
 Some video conferencing defaults are too small for a participant to see sign language or lip-read, especially if many participants are on screen.
 Several video conferencing systems provide only a thumbnail view of video when a screen or presentation is shared, which is too small to understand sign language or lip-read.
 Text chat is a critical feature for participants to alert hosts to accessibility problems, and receive responses.
 In some conferencing systems, too many videos on screen lower the resolution or frame rate too much for sign language to stay intelligible.
 When multiple deaf or hard of hearing people participate, it is recommended that they be able to all see each other at a glance.
 Some of the tips described in the next section are easier to implement with lower cognitive load if moderator roles can be split across multiple people.