Accessibility of Remote Meetings

From Research Questions Task Force

What's on this page

LATEST VERSION OF ACCESSIBILITY OF REMOTE MEETINGS

PAGE BELOW IS OUTDATED

This page is an interim collection point for accessibility guidance, best practices, gap identification, and other relevant information related to cross-disability accessibility of videoconferences and some other forms of remote meetings. Many of these services use some portion of Web-based standards.

Given increased reliance on different forms of remote interactions during the COVID-19 pandemic, it is vital to ensure accessibility of all kinds of remote interactions for people with disabilities, and to rapidly work to improve accessibility support in these technologies. The page therefore also includes and/or links to guidance and resources for non-video teleconferences; for extended remote meetings; and an introduction to guidance for the education sector, telehealth, telework, and other sectors that are currently relying more heavily on remote and/or virtual formats.


Status

This is an early draft of a collection of accessibility issues relating to use of videoconferencing and other forms of remote collaboration. The structure and contents of the page are still evolving, and it may include issues and/or resources that are not yet categorized. Information collected here may be moved or delegated to different groups and documents. Please note additional status information in some sections. Comments and input are welcome filing a GitHub issue at [TBD].

Introduction

The Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C) has existing guidance relevant to videoconferencing and other types of remote meetings, as well as work underway on many different aspects of accessibility of remote meetings. This document highlights different types of resources in those areas. Please feel free to raise questions and/or comment on this work, or to suggest improvements, at [TBD].

Opportunities to provide comments

Getting Involved in WAI work on remote accessibility

Applicable W3C/WAI Guidance

This section contains guidance relevant for videoconferencing and remote meetings from Web Accessibility Initiative Guidelines, of which there are three: for Web content and applications; for user agents (browsers, etc); and for authoring tools (tools use to create content and applications. The first two guidelines are W3C Recommendations (Web standards); the third is a normative W3C Working Group Note.

Please see the following section for identification of gaps in coverage of accessibility guidance related to accessibility of remote meetings and other forms of remote collaboration.

Web Content Accessibility Guidelines (WCAG)

There are three aspects of a remote meeting for which accessibility guidance is available in Web Content Accessibility Guidelines (WCAG) 2.1.

  • The user interface of the client software (e.g., videoconference platform) that is used to conduct the meeting. To be accessible to meeting participants with disabilities, the videoconference user interface should conform to WCAG 2.1 at level AA.
  • Any prepared content (e.g., documents, presentation slides, prerecorded multimedia) that is shared with or shown to meeting participants. Policies typically specify that documents, presentations and related materials should conform to WCAG at Level AA.
  • Live audio and video communications that take place among meeting participants. This is the real-time communication component of the meeting. The following WCAG 2.1 success criteria provide support for accessibility of live audio and video:
    • Success Criterion 1.2.4: Captions (Live). This is applicable to real-time communication by meeting participants. The quality of captions is essential to effective communication. It should be noted that the use of automatic speech recognition (ASR) technology to generate captions will not yield sufficiently high quality without manual intervention to correct errors. Moreover, such correction is difficult to perform effectively in real time.
    • Success criterion 1.2.9: Audio-only (Live). This success criterion specifies that a text transcript of live, audio-only content be provided. In a meeting, this could be achieved by transcribing the dialogue in real time. As with captions of videoconferences, automatic speech recognition will not yield sufficiently high quality captions for most settings.
    • For user interfaces presented live in a meeting via screen sharing: success criteria 1.4.1 (Use of color), 1.4.3 (text contrast), 1.4.6 (contrast - enhanced), 2.3.1 (three flashes or below threshold), 2.3.2 (three flashes).

Note: sign language interpretation greatly facilitates accessibility of meetings for sign language users. Sign language interpretation is a Level AAA requirement of WCAG 2.1 for prerecorded audio content only. However, sign language can be streamed into a videoconference window during a live videoconferencing session; this may need clarification in the current WCAG 2.x series.

Possible Additions to Future WCAG Guidelines

(@@@@ Given the immediacy of the current situation, if there are a limited number of recommended techniques relevant to accessibility of the video-conferencing environment that could be developed relatively quickly, in coordination with AGWG, perhaps these could be added to WCAG 2.1 techniques without waiting for WCAG 2.2. For instance, hypothetically:

  • [@@@@ DRAFT In a video-conferencing environment, any document shared in a video-conferencing window should either meet WCAG 2.1 AA for [xyz] success criteria, or link to an accessible version of the relevant source file.
  • (@@@@ DRAFT Sign language interpretation is provided for live audio content.)
  • Other potential techniques?

(@@@@ We should also consider where there may be one or more clarification notes that are timely and feasible to add to WCAG 2.2.

  • @@@@ If sign-language interpreting gets listed as AA for video-conferencing environments, would that need to be an additional success criteria? [There may be other approaches for this]

Authoring Tool Accessibility Guidelines (ATAG)

Authoring Tool Accessibility Guidelines (ATAG) 2.0 offers normative guidance concerning the development of authoring tools that support the creation of content that meets WCAG accessibility requirements. ATAG 2.0 also specifies requirements for accessibility of the user interface of an authoring tool.

Although a meeting platform is not, in itself, an authoring tool, authoring tools are used to prepare materials such as presentations and documents for dissemination in remote meetings. These tools include document editing and file format conversion software. In addition, a meeting platform may be integrated with an authoring tool to enable the real-time, collaborative writing or editing of documents or other content during a meeting.

In summary, ATAG 2.0 is applicable as follows.

  • Authoring tools that partly or fully conform to ATAG 2.0 at any level of conformance are the preferred environment in which to create documents, presentations, multimedia and other materials disseminated to participants in remote meetings.
  • Authoring tools included in or associated with platforms used for remote meetings, such as real-time document editing environments that allow content to be created and edited collaboratively during a meeting, should implement ATAG 2.0.

User Agent Accessibility Guidelines (UAAG)

The following success criteria are relevant to the design and implementation of meeting platforms.

  • 1.1.4 Facilitate Clear Display of Alternative Content for Time-based Media:

For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the following are all true: (Level A) 

   Don't obscure controls: Displaying time-based media alternatives doesn't obscure recognized controls for the primary time-based media.
   Don't obscure primary media: The user can specify that displaying time-based media alternatives doesn't obscure the primary time-based media.

   Note: Depending on the screen area available, the display of the primary time-based media (slides, documents, etc.) may need to be reduced in size to meet this requirement.

Reference for 1.1.4

  • 1.1.5 Provide Configurable Alternative Content Defaults:

The user can specify which type(s) of alternative content to render by default for each type of non-text content, including time based media. (Level AA) Reference for 1.1.5

  • 1.1.6 Use Configurable Text for Time-based Media Captions:

For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the user can configure recognized text within time-based media alternatives (e.g. captions) in conformance with 1.4.1. (Level AA) Reference for 1.1.6

  • 1.1.7 Allow Resize and Reposition of Time-based Media Alternatives:

The user can configure recognized alternative content for time-based media (e.g. captions, sign language video) as follows: (Level AAA) 

   Resize: The user can resize alternative content for time-based media to at least 50% of the size of the top-level viewports.
   Reposition: The user can reposition alternative content for time-based media to two or more of the following: above, below, to the right, to the left, and overlapping the primary time-based media.

   Note 1: Depending on the screen area available, the display of the primary time-based media can need to be reduced in size or hidden to meet this requirement.
   Note 2: Implementation can involve displaying alternative content for time-based media in a separate viewport, but this is not required.

Reference for 1.1.7

Gaps in Existing Guidance for Remote Accessibility

This section includes identification of gaps in existing W3C WAI guidance, as it might apply to accessibility of remote meetings and other forms of remote collaboration. Currently it only includes relevant auxiliary guidance with potential relation to the Web Content Accessibility Guidelines. We welcome gap identification with regard to other documents in this suite of resources on accessibility in remote settings.

Possible Additions to Future WCAG Guidelines

(@@@@ Given the immediacy of the current situation, if there are a limited number of recommended techniques relevant to accessibility of the video-conferencing environment that could be developed relatively quickly, in coordination with AGWG, perhaps these could be added to WCAG 2.1 techniques without waiting for WCAG 2.2. For instance, hypothetically:

  • [@@@@ DRAFT In a video-conferencing environment, any document shared in a video-conferencing window should either meet WCAG 2.1 AA for [xyz] success criteria, or link to an accessible version of the relevant source file.
  • (@@@@ DRAFT Sign language interpretation is provided for live audio content.)
  • Other potential techniques?

(@@@@ We should also consider where there may be one or more clarification notes that are timely and feasible to add to WCAG 2.2.

  • @@@@ If sign-language interpreting gets listed as AA for video-conferencing environments, would that need to be an additional success criteria? [There may be other approaches for this]

Input to Best Practices for Hosts and Participants

This section is in DRAFT status, and proposes suggested practices that may be followed to improve the accessibility of remote meetings.

Note: these suggestions are informative only. They do not constitute normative W3C/WAI guidance. However, future normative WAI guidance may address aspects of the accessibility of remote meetings, and of real-time communication in general, identified in this document; and these may be helpful for reference in the meantime.

Meeting Hosting and Participation

@@@@ (Status Note) The items in this section need to be differentiated between host and participant practices, and organized into a more manageable flow.]

@@ Note existing WAI guidance in How to Make Your Presentations Accessible to All. Assume that we want to integrate the guidance below with that. Probably also want to provide filters for in-person/remote, organizers/speakers/participants, and maybe others.

Hosts and participants in remote meetings should:

  • Prepare documents, presentations, multimedia and other materials so as to conform to Web Content Accessibility Guidelines (WCAG) 2.1, preferably at Level AA or beyond.
  • Ensure that the files containing such documents, presentations, multimedia, etc., are available directly to meeting participants, and that screen sharing is not the only means of obtaining these materials.
  • Be prepared to engage a captioning service, or to provide captions.
  • Be prepared to engage a sign language interpretation service, or to provide sign language interpretation.
  • Be prepared to provide alternatives to any aspects of the remote meeting platform that are not accessible to meeting participants. For example, if a tool used to coordinate turn taking in a meeting (e.g., a "hand raising" control) is not accessible to keyboard-only users or to users of assistive technologies, offer alternative means of managing turn taking.
  • Create accessible meeting notes that can be made available to participants after the meeting.
  • Become familiar with the accessibility features of the meeting software platform. See #References below for a partial list of links to accessibility information offered by well known meeting platform providers.
    • @@Address any accessibility issues in the meeting platform. For example, in some platforms, screen reader users cannot override chat interruptions, and when there is a lot of chat, they cannot hear the speakers.
  • Request that all participants test their audio and video in advance of any meeting.
  • Remind all participants to, if possible, ensure that their faces, including their mouths, are visible and well-lit in the videoconferencing window.
  • Request that any participants using virtual backgrounds (photo or video) test the quality of their projection to ensure that there is no flicker of the participants' image.
  • If the sound degrades during a videoconference, request that participants turn off their video to see if that improves the audio quality.
  • If streaming captions or streaming sign language interpreting will be used during a videoconference, make sure to select a videoconferencing platform in which participants can anchor and freely re-size any window in which these communication accommodations will be displayed, independently from the windows showing any content (for instance, slides, whiteboard, etc), or any other speaker.
  • Allow participants to use a variety of meeting connection methods (e.g. computer, app, telephone) to maximise accessibility and choice for participants with disabilities. This may also lead to additional in-meeting accessibility considerations (e.g. the need to live caption telephone participants)
  • @@@@ [I don't believe this is the typical meaning of the term "mixed mode". Is there another way to explain this?] Avoid mixed-mode meetings, i.e. having multiple participants using one connection.

A more detailed elaboration of users' accessibility needs in these scenarios may be found in the RTC Accessibility User Requirements.

Meeting Platform Procurement

Persons responsible for procuring or selecting a platform on which to conduct remote meetings should

  • Give preference to platforms with user interfaces that conform to WCAG 2.0 or 2.1, with 2.1 conformance being superior.
  • Consider the diversity of operating systems for which the remote meeting platform is supported. Not all access needs or assistive technologies are equally served by each of the popular operating systems. Therefore, the more choice the user has of underlying operating system, the more likely it is that accessibility and compatibility needs can be satisfied.
  • Consider interoperability of remote meeting platforms with the public switched telephone network, and with telephony standards such as the Session Initiation Protocol (SIP). Offering telephone-based access to the meeting allows users greater opportunities to participate using hardware and software that satisfy their access needs and with which they are familiar.
  • Take into consideration the extent to which authoring tools included in or interacting with meeting platforms implement Authoring Tool Accessibility Guidelines (ATAG) 2.0, to facilitate creation of accessible content. Some relevant considerations are discussed in #Authoring Tool Accessibility Guidelines (ATAG), below.
  • Consider what authoring tools should be recommended in preparing content (documents, presentations, etc.) for dissemination in remote meetings, taking into account the requirements of Authoring Tool Accessibility Guidelines (ATAG) 2.0.
  • Evaluate other accessibility-related features of meeting platforms in light of users' access needs, as described here and in the Real-Time Accessibility User Requirements.

Meeting Platform Development

Meeting platform developers should

  • Ensure that all aspects of the user interface of the platform conform to WCAG 2.1, at Level AA or beyond.
  • For any authoring tool that is incorporated into the platform (e.g., supporting real-time, collaborative editing), implement ATAG 2.0 as well.
  • Provide the ability to record a specific user view during throughout the meeting such as a sign language interpreter.
  • Understand the platform-related issues identified in this document, and detailed in RTC Accessibility User Requirements. Take appropriate steps to enhance the platform to improve its capacity to satisfy users' access needs. The Accessible Platform Architectures Working Group has published a draft of RTC Accessibility User Requirements. This document outlines needs that users with disabilities have in accessing applications that employ real-time communication, including software that enables remote meetings. These user needs lead to technical requirements that can be satisfied by various components of the technology stack: Web standards, user agents (including Web browsers), assistive technologies, and RTC applications such as teleconference and video conference client software.

Sector specific guidance

@@@@ DRAFT -- Section needs to be populated with additional sector-based examples. Also we need to tie this to relevant W3C WAI guidance, sector by sector.

Education/Learning Managements Software (LMS)

  • Ensure that the LMS content referenced in a remote meeting adheres to WCAG 2.0 or 2.1 Level AA or greater accessibility requirements including curriculum modules, slide decks and assignment materials.
  • Ensure that authoring capabilities within LMS platform comply with the Authoring Tool Accessibility Guidelines (ATAG) 2.0 AA.
  • Embed the remote meeting platform into the LMS platform to make it easier for people with disabilities to access all learning tools in the one place.
  • Ensure that the remote meeting login credentials and LMS credentials are consistent
  • Ensure that the embedding of a remote meeting solution into an LMS platform does not impact on customised keyboard shortcuts*
  • Ensure that the posting of a remote meeting recording, such as a lecture, retains its media accessibility features such as captions.

Requirements needing support at application/platform level

Note: Some of these considerations are addressed in greater detail in RTC Accessibility User Requirements, a working draft that is currently open for public review. This draft also offers additional considerations, based on analysis of users' needs.

  • Real-time Text (RTT) support, in which characters are sent to the other party to the communication almost as soon as they are entered, instead of waiting for an entire message to be composed before it is transmitted This allows for a more immediate conversational exchange (e.g., participants can interrupt each other), and often proves to be a more effective communication method for people who are deaf or hard of hearing than an "instant message" style of textual communication.
  • Interoperability with relay services (allowing them to be brought into a conversation, as needed, to support communication, including provision of sign language interpretation).
  • Support for enabling the user to switch seamlessly between modes of interaction (voice, video, real-time text, sign language interpreting).
  • Support for an "instant message" style of communication in which the entire message is transmitted as a unit, rather than character-by-character. (This may be preferred, for example, by screen reader users.)
  • Minimum audio and video quality requirements. Such requirements, addressing issues of video frame rates, audio clarity, and synchronization of audio and video are identified in the working draft of RTC Accessibility User Requirements, with reference to applicable standards.

Additional Issues

[Status: @@@@ Entire section needs to be sorted into categories above.]

  • Accessibility of video-conference controls, including user notification upon activation of camera-on status, so that someone who cannot see a visual activation sensor is not broadcasting video unawares. @@@@ This should already be addressed by WCAG. Should we add a section to this document in which such issues are specifically noted, as they may be very consequential from the user's perspective? @@@@
  • Privacy: to what extent disclosure of one's disability-related needs is necessary or appropriate in enabling a remote meeting to be made accessible. To what extent is it a question of meeting the needs of the individual, if the technological capabilities are in place? Do remote meetings offer an opportunity for people with disabilities not to disclose their disability status, and to what degree can this option be preserved while still satisfying their access needs? @@@@ Is this out of scope for the current document? @@@@
  • [@@@@ Add security provisions]
  • Lack of interoperability among remote meeting/teleconference applications, in the absence of widely accepted standards for federated protocols in this area. Each teleconference service requires one to use its own application; the user cannot choose the client application independently of the service provider. This may be contrasted with email (decentralized and federated), telephony systems based on Session Initiation Protocol (SIP), and other Internet standards-based systems. The implications of this lack of interoperability for accessibility include the user's having to learn different interfaces for different remote meeting platforms, and inconsistencies in the features - including accessibility-related features - provided by the client software for the different platforms.
  • Inaccessibility of "screen sharing" facilities, which are typical of remote meeting services. @@@@ Addressed above in recommending that materials be provided which conform to accessibility guidance? @@@@
  • Ensuring that documents or other files shown by meeting participants are shared in an accessible manner by disseminating the original files, rather than by relying on screen sharing alone. [rqtf-discuss-mar25; @@@@ now incorporated into text above, so issue should be closed? @@@@]
  • Accessible meeting elements: ensuring that files and other media that provides critical context to a meeting also adhere to accessibility criteria. e.g. websites referenced within a meeting are compliant to accessibility standards, documents such as Word, PowerPoint and PDF files contain accessible content and externally referenced media contain accessibility features such as captions and audio description. @@@@ discussed above? @@@@
  • Ensuring that live caption/transcript generation services are sufficiently accurate and reliable to satisfy users' needs; avoiding inappropriate dependence on automatic speech recognition technology under conditions in which it cannot exceed accuracy thresholds. [rqtf-discuss-mar25; @@@ now incorporated in text above, should be closed? @@@@]
  • Learning platform support: education-related scenarios where remote meetings are used as a component of an LMS require feature accessible integration into other aspects of the learning platform @@@@ Now addressed above? @@@@

only partially integrated so far

Advice for W3C on inclusive video conferences, from Immersive Captions Community Group -- needs categorization by role, and integration.

  • Behaviors "pin" a number of people, not just one person.
    • CART, Interpreters
    • Positioning of spoken interpretation
  • Incorporate captioning into products
    • where would it go? how do you handle multiple people
    • allow ability to move the captions, don't force it at a single place
  • Allowing superimposition of a/few windows, like a captions window
  • Adjust size of different windows (helps low vision)
  • Don't always obfuscate foul language, make it an option
  • Allow different prioritization of audio and video (for low bandwidth situations)
  • Adjust control of captions (opaqueness, color, size)
  • Camera:
    • can we minimize brightness adjustment.
    • disable autofocus (hands in front of camera/face blurry)
  • Large groups: emphasize chat usage
  • Discovery of features is a problem (what exists, how to use, etc)
  • Need to be able to capture a recording of the interpreter in the meeting [Consider moving this into the RAUR]

References

To-Do

Specify next steps here. Keep updated.

  1. Specify what kind of guidance this is -- best practices only? Or, in some cases, reminder of already-applicable requirements?
  2. Re-Title to Remote and Hybrid -- or will hybrid need to a separate section? (Needs discussion, once examples are available)
  3. Discuss and process "issues to sort" and "only partially integrated" -- this may be a major chunk of work
  4. Scan by environment, and functional needs, to identify gaps -- e.g., are the needs of people with xyz functional needs comprehensively addressed here?
  5. Scan with FAST checklist
  6. Add workflow next steps here
  7. Map each section to other relevant WAI documents, for instance, Making Presentations Accessible, and build in a plan to round-trip the links, and identify status of those other pages
  8. Format into sections of audience-specific guidance: platform vendors; platform procurement; meeting host; meeting participants; other?
  9. Start populating a parallel, or extended, set of guidance for hybrid meetings -- develop a few examples to illustrate the relation between the different sections
  10. Consider intended final format: possibly along the lines of "Making Audio and Video Media Accessible" e.g., "Making Remote and Hybrid Meetings Accessible" with multiple sub-pages by audience, and a bonus page or pages for hybrid meetings
  11. Maintain a "New items to be sorted, and gaps to be filled" section
  12. Link to "bugs to fix" from the APA Github repository (bugs in this document)
  13. Add an action section to track discussions with video-conference vendors, off-page
  14. Themes to promote (these should go in the platform vendor section, for instance:
    1. use of open, accessibility-support standards
    2. interoperability
  15. Devise a better introduction for the page, then mini-intros for each of the audience-facing section?
    1. add section status notes after each, and intended format
  16. Use parallel syntax within each section
    1. write these best practices in understandable and actionable language
  17. Clean up format where nesting is broken
  18. Review overall document flow, to see that it makes sense for people landing on the page
  19. Tersify language wherever possible. Careful about overuse of "Consider..." which may not really help people figure out what to do.
  20. Reprioritize and re-order this to-do list so it makes more sense.
  21. Within each collection of guidance, try to capture parallel levels of generality vs specificity
  22. Make it simpler overall.
  23. Link out to related guidance, outside and inside W3C.
  24. Add a section on survival in video meetings for participants in meeting

Contributors

Judy Brewer, Jason White, Scott Hollier, Josh O Connor

Retrieved from "https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/index.php?title=Accessibility_of_Remote_Meetings&oldid=604"