Collaboration Tools Accessibility User Requirements

W3C Group Draft Note

More details about this document
This version:
Latest published version:
Latest editor's draft:
Commit history
Janina Sajka
(Centre for Accessibility Australia)
GitHub w3c/ctaur (pull requests, new issue, open issues)


This document outlines various accessibility-related user needs, requirements and scenarios for both synchronous and asynchronous web-based collaboration tools. These tools typically include one or more specific collaborative features such as content editing by multiple authors, support for comments annotations, and revision control in real-time synchronous sessions, or asynchronously. Asynchronous tools are more commonly known as revision control systems rather than collaboration tools though their functionality is otherwise very similar. The Cloud-based office application suites from Google and Microsoft are well-known examples of synchronous, real-time collaboration tools, though they also support asynchronous collaboration. Web tools built on git are well-known example of asynchronous collaboration tools.

The accessibility user needs and requirements described in this document may be implemented in the collaboration tool itself, or in an assistive technology application such as a screen reader or screen magnifier. Widely used desktop applications such as word processors and spread sheets also commonly support collaboration features. We take a holistic approach to give foremost priority to the user's perspective, leading to the identification of features and solutions that may be implemented by different components of the software stack involved in performing a collaborative task.

Although the user needs and requirements identified in this document are non-normative, they may influence the development of future accessibility guidelines, normative technical specifications, or features of collaboration tools and assistive technologies. They are relevant to software developers who contribute to the collaborative experience.

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

This document was published by the Accessible Platform Architectures Working Group as a Group Draft Note using the Note track.

Group Draft Notes are not endorsed by W3C nor 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.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 03 November 2023 W3C Process Document.

Editor's note

Editor's Note: Contributing to this Document

This updated working draft publication is a document intended to become an Accessible Platform Architectures (APA) Note. The intent of this (and all) APA working draft publications is to gain a wider review of its content and solicit feedback on user needs that may have been missed, underrepresented, or sub-optimally described.

APA encourages review and feedback from all accessibility perspectives to ensure future drafts are as comprehensive as possible.

1. Introduction

1.1 What are collaboration tools?

For the purposes of this document, a collaboration tool is any software that supports features designed to facilitate the interactive creation, editing or annotation of content by multiple contributors, whether working in simultaneous collaboration or asynchronously. Examples of collaboration tools include

1.2 Distinctive features of collaboration tools

This document focuses primarily on features unique to collaboration tools, rather than features which they share with other Web applications or with application software in general. Indeed, any tool that provides one or more of the features enumerated here may benefit from the user needs and corresponding requirements elaborated in the sections that follow.

The distinctive capabilities of collaboration tools are illustrated by the examples described in the section: 1.1 What are collaboration tools?. It is important to consider how these features are manifested in the tool's user interface. From this perspective, the distinguishing features may be described as follows.

Real-time and asynchronous co-editing
A feature enabling multiple authors to edit the same content simultaneously or over days, weeks months, and years. In synchronous co-editing, the changes introduced by different authors in real-time are combined almost immediately, using algorithms such as operational transformation [concurrency-control]. The combined changes are then made immediately visible in all of the participating authors' editing sessions. The effect is that each author may perceive, in real time,
  • Edits proposed by collaborators,
  • The location of other editors' focus within content.
Asynchronous edits, on the other hand, are made visible on document reload.
Annotation of content with comments
Some tools enable users to associate comments with parts of the content that is being read or edited. In systems such as word processors, replying to comments is supported, allowing threads of discussion to be associated with parts of a document.
Comparing revisions
Some systems can display the differences between revisions of content for purposes of comparison.
Suggested changes
Some word processors can show changes (insertions, deletions and formatting-related modifications) made by collaborators, which an author can choose to accept or reject. These revisions are sometimes referred to as suggested changes or as tracked changes. Each change may be accompanied by metadata, for example the identity of the author who made the change, and a time stamp.
Access controls
Some collaborative environments support access controls, allowing restrictions to be imposed on modification of part or all of the content. Permission to modify content may be granted on a granular basis to specific individuals or to groups of users. For example, in a collaborative tool for creating fillable forms, some users may only be allowed to change the values of input fields (i.e., to complete a form), whereas others may be free to edit any aspect of the document, including the addition, deletion and rearrangement of form fields.

Collaboration tools differ widely in the nature of content that may be edited. They also differ widely in the user interfaces presented to users. For example:

As the preceding cases suggest, collaboration tools are not restricted by the kind of content that may be edited. Thus, tools that support editing of static images, mathematical notation, or other content types are also within the scope of this document. However, only the collaboration-related aspects of such systems are addressed here. The accessibility issues arising from creating and editing different types of content are not considered in this document, as they are separate problems from the user needs associated with the collaborative features of the tools.

Nevertheless it is important that collaborative tools support the full range of editing functions associated with making web content accessible. Among others this would include the ability to add headings, provide alternative text for images and add captions to videos.

Some collaboration tools support accessibility by mapping unique keyboard commands. Some also organize their feature options in unique menus or uniquely located menus. We prefer collaboration tools that utilize standard menu organization and typical keyboard commands now well known to users from the stand-alone desktop environment. Standard controls require far less learning from the user, whereas specific accessibility modes with custom keyboard commands, and with menus that shift their location on screen pose significantly steep learning challenges to most users with disabilities, not just users with cognitive and learning disabilities.

1.3 Scope and Applicability of this Document

Accessibility-related guidance provided in this document is applicable to a wide variety of tools. No unnecessary restriction is placed on the types of Web-based software to which it may reasonably be applied.

If a tool implements one or more of the distinctive features described in section 1.2 Distinctive features of collaboration tools, then the guidance in this document which addresses each such supported feature is relevant and applicable to the tool. Thus, the scope of the document includes any tool implemented using Web technologies that implements at least one of the distinctive features for which guidance is offered in the sections that follow.

For example, an annotation tool supporting the association of shared comments with selected text in Web pages would offer only a single feature described in this document. For this reason, only section Annotations would be relevant to the tool.

1.4 Collaboration tools and accessibility

By following established guidance, notably that of Web Content Accessibility Guidelines (WCAG) [wcag22], designers of collaboration tools can help ensure that their user interfaces are perceivable to and operable by a wide range of users with disabilities. Following the Guidelines also enables user interfaces to be more understandable, and to be robust in their support for a range of user agents and assistive technologies. In addition, non-normative guidance of a general nature on improving accessibility for people with cognitive and learning disabilities has been published in [coga-usable]. However, implementing current guidelines and suggested practices is not sufficient by itself to ensure that the user interface of a collaboration tool can be understood and used efficiently by people with disabilities. Thus, conforming to WCAG may well be insufficient for collaborative environments. For example WCAG does not inform automated interface simplification — a general web accessibility requirement being considered in APA's WAI-Adapt Task Force.

The collaboration features of these tools are necessarily complex. This can impose significant cognitive demands on many users, not only users with specialized accessibility requirements. This is especially true for users of screen readers, screen magnification and color contrast assistive technologies, as well as for persons living with various cognitive and learning disabilities. Many users cannot track updates on multiple locations simultaneously, Rather, they must view and comprehend the interactive elements of the application's features sequentially, for example in speech or braille for screen reader users. A screen reader or magnifier used in a collaborative application may well present suggested changes and comments in one section of the screen while the user is reading a document in a word processor. The user may also be expected to be communicating verbally with fellow collaborators (e.g., in a meeting) while undertaking editing tasks. Moreover, at any time, incoming changes made by collaborators may alter the text that the user is reading or editing in real time.

Due to the cognitive demands created by collaboration tools in the practical and social contexts in which they are used, strategies for improving accessibility are desirable that extend beyond current W3C guidance.

Thus when we talk about collaborative tools we necessarily must consider accessibility burdens imposed by their concomitant complexity. In truth collaborative tools are necessarily complex interfaces for all users, and not only persons with various disabilities. A fairly common example is the use of arbitrary color to flag edits put forth by different collaborators. However, identifying collaborators only by colorization violates WCAG 2.2 Success Criterion 1.4.1 as described below in User Need 11.

1.5 Social Considerations

Collaborative tools should support all identified accessibility features in order to provide comprehensive accessibility. However, it is unlikely all features will be needed by any individual collaborative team effort. We assume persons with disabilities are brought into collaborative teams because of the contributions they are expected to make in the project. Teams are encouraged to focus on accommodating the specific accessibility needs of participating team members in order to operate most efficiently and productively.

2. Terms

An acronym for What You See Is What You Get. As described by Wikipedia, it refers to software which allows content to be edited in a form that resembles its appearance when printed or displayed as a finished product, such as a printed document, web page, or slide presentation. WYSIWYG implies a user interface that allows the user to view something very similar to the result while the document is being created.

3. User need definition

Specific user needs are frequently defined both by task required to achieve a particular goal and also by environmental conditions. Context matters. For example, the cognitive demands imposed by interacting with the collaboration-related features of an application depend not only on the needs and capabilities of the user, including the possible presence of assistive technology, but also on the context. A collaborative task that the user can perform independently while working alone in a distraction-free environment may become cognitively burdensome if performed in a situation such as a meeting. Working with comments and suggested changes in a document may become more cognitively demanding if other authors are simultaneously editing the same content, and the user needs to be aware of their activities (e.g., to avoid introducing conflicting changes) while still performing the editing task. The use of different input types and methods, such as speech input or switch-based input, can affect the amount of time required to enter and edit text, as well as the user's ability to respond to potentially disruptive changes introduced by collaborators.'

4. Real-Time co-editing


WCAG requires that status messages be made available to assistive technologies. See Web Content Accessibility Guidelines (WCAG) 2.2 [wcag22], success criterion 4.1.3, and the associated definition of status message.

5. Annotations


See Web Content Accessibility Guidelines (WCAG) 2.2 [wcag22], success criterion 1.3.1.


REQ 8 may be valuable to users in general, and it should be considered for inclusion as a feature of collaboration tools themselves.

6. Version control features

6.1 Suggested changes

6.2 Presenting Differences Between Revisions

6.3 Summarizing Effect of Revisions


Although it may be useful to support automatic summary generation by technologies such as large language models, the state of the art as of the time of publication suggests implementers should exercise caution. Inaccurate summaries of changes may be worse for users than their absence. For this reason, summaries written by human authors are generally preferable to those authored by automated large language models.

7. Notifications and Messages

Collaboration tools may send notifications to the user for a variety of reasons. For example, a user may be notified if a collaborator asynchronously submits changes to a document or project, or adds a comment. These notifications may be delivered via operating system facilities, or by a messaging service, such as e-mail or an instant message protocol. Moreover, the collaboration tool may support commenting, issue tracking, or other forms of interaction via external messaging. These optional capabilities are addressed in the following user needs and system requirements.

8. Access Controls

A collaborative environment may provide access controls to restrict the modification of content to specified individuals or groups of users. Moreover, access controls may be applied to the entire content, as in a document which is marked as read-only in a text editor or office application, or they may restrict editing to designated parts. Depending on the capabilities of the application, permissions may be changed by an authorized user during a collaborative editing session.


Web Content Accessibility Guidelines (WCAG) 2.2 [wcag22] should be consulted for guidance on ensuring that the user interface for configuring access controls meets appropriate accessibility requirements.

9. General Guidance on Implementing Accessibility Features of Collaborative Environments

To facilitate effective collaboration, applications should be designed to respect conventions of user interface design that are likely to be expected by users, including those who have disabilities.

A. References

A.1 Informative references

Making Content Usable for People with Cognitive and Learning Disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 29 April 2021. W3C Working Group Note. URL:
Concurrency control in groupware systems. Clarence A. Ellis; Simon J. Gibbs. Proceedings of the 1989 ACM SIGMOD international conference on Management of data. 1989.
Web Content Accessibility Guidelines (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 5 October 2023. W3C Recommendation. URL: