Collaboration Tools Accessibility User Requirements

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

• A Web-based text editor or word processor that enables multiple authors to edit content simultaneously while discussing their edits during a Real Time Communications (RTC) teleconference, with each contributor's changes being integrated into the resulting text and propagated in real time to the collaborators.
• A Web-based text editor or word processor that enables multiple authors to edit content asynchronously over many days and week, with each contributor's changes being integrated into the resulting text and propagated on next load to the collaborators.
• A tool that enables Web pages to be annotated with comments that are automatically made available to other users of the annotation service who access the same pages with suitable software. The software may be included in a user agent, or it may be supplied as an extension.
• An Integrated Development Environment (IDE) that supports the collaborative editing of program source code in real time or asynchronously.
• A wiki that supports version control, for example by enabling authors to revert to prior versions of a page or to view the differences between two versions.
• A midi or audio editing application that allows real-time synchronous or asynchronous audio content editing. Collaborators hear edited content on demand during a teleconference editing session or on content refresh when editing asynchronously.

This document focuses on features unique to collaboration tools, rather than features which they share with other Web applications. Most especially this document avoids discussion of features applicable to software in general. However, any software 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 editor can choose to accept or reject. These revisions are sometimes referred to as suggested changes or 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:

• Word processors typically provide a what you see is what you get (WYSIWYG) interface based on a rendered view of the content.
• Editors designed for source code or markup language text development do not provide a rendered view. In these applications, indentation and syntax highlighting may be the only visual cues provided to the structure of the code or markup available in the editing environment.
• In collaborative video editors, candidate video renditions may be played in side by side windows for purposes of comparison and editing decisioning.
• By their very nature, audio alternatives presented in music or sound editing environments must be played sequentially, and their distinctions remembered by the user in the comparison and decisioning process.

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 collaboration-related aspects of any content editing environment are addressed here. Accessibility issues particular to creating and editing various types of content are not considered in this document.

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.

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 quickly become cognitively burdensome when performed during a working teleconference session. Working with comments and suggested changes becomes more cognitively demanding when 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 significantly 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.

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, broadly applicable guidance 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. For this reason, the unique cognitive demands established by collaborative content creation applications can impose barriers to access which are addressable, in part, by making appropriate software design and implementation choices. Additional control of cognitive demands can be achieved by using the application and any assistive technologies appropriately in a collaborative setting, and by ensuring that the social context in which the collaboration occurs supports participation by contributors with disabilities (see section 1.5 Social Considerations).

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 an in-person or RTC meeting) while undertaking editing tasks or comparing multiple revisions of content. Moreover, in applications supporting real-time collaborative editing, incoming changes made by other contributors may alter the content that the user is reading or editing in real time. These cognitive demands can be exacerbated when one is working with an unfamiliar user interface such as a rarely used RTC client (See our RTC Accessibility User Requirements [RAUR] publication).

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 must consider accessibility burdens imposed by their associated complexity. In truth, collaborative tools are necessarily complex interfaces for all users, and not only persons with various disabilities. The salient point here is that a failure to design to accomodate persons with disabilities appropriately will inevitably prevent their participation in collaborative work. What constitutes challenging complexity for most users will inevitably become an insurmountable barrier for some persons with disabilities.

A fairly common accessibility failure is the use of arbitrary color to flag edits put forth by different collaborators. However, identifying collaborators only by colorization violates WCAG Success Criterion 1.4.1 as described below in User Need 11.

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.

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 Our scope: 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 3. Annotations would be relevant to the tool.

• User Need 11: Assistive technology users need to be able to read the text with information included about suggested changes (i.e., insertions, deletions, or formatting modifications proposed by collaborators). Assistive technology users and those with learning or cognitive disabilities also need to be able to read content being edited without the distraction of insertion and deletion annotations.
• REQ 11A: Provide a mode of operation in which details of insertions, deletions, and formatting changes are appropriately presented as collaborators read the content. These details should include time stamps and identification of who made the change together with any annotations the editor may have provided by way of explanation.
• REQ 11B: Provide a mode of operation in which users can read the unmodified content, or if they prefer, the revised content, with suggested changes applied, without any annotations indicating revisions.
• User Need 12:All users, and particularly users with color blindness need to be able to distinguish insertions, deletions, and unaltered text effectively.
• REQ 12: Provide distinctions over and beyond just color to identify inserted and deleted text as required by WCAG 2.2 Success Criterion 1.4.1: Use of Color.

• User Need 13: Users need to be able to compare revisions in meaningful units (words, sentences, lines, blocks of code, a side-by-side presentation of two graphic renderings, etc.), according to the nature of the content, to maximize comprehension.
• REQ 13: Provide at least one mode (and preferably several) that present differences in a content appropriate manner.

• User Need 14: Users with learning or cognitive disabilities and users of assistive technologies sometimes need support in identifying revisions and understanding their effects.
• REQ 14A: Provide, with timestamp and author indication, a mechanism to identify and summarize a series of changes to some portion of content.
• REQ 14B: Provide, with timestamp and author indication, a mechanism to identify and summarize individual comment threads.
• REQ 14C: Provide, if technically feasible, a mechanism allowing any user automatically to generate a summary for themselves of content or a comment thread at any time. Project editors should have the ability to revise and commit a summary to the content in collaborative development as a permanent feature of the collaborative effort.
• REQ 14d: Whenever AI rather than human authoring is used to generate summaries, indicate that the summary was auto-generated, but also provide the ability for an editor to edit or replace the auto-generated summary. Indicate any special circumstances, e.g. an auto-generated plain language summary.