Collaboration Tools Accessibility User Requirements

This document outlines various accessibility-related user needs, requirements and scenarios for collaboration tools. The tools of interest are distinguished by their support for one or more specific collaborative features. These features include real-time editing of content by multiple authors, the use of comments or annotations, and revision control. A Web-based text editor or word processor offering all of these features would be a central example of such a collaboration tool.

The accessibility-related user needs and corresponding requirements described in this document may be implemented in the collaboration tool itself, or elsewhere, for example in an assistive technology such as a screen reader. The scope of the discussion is not limited to problems that can be solved in the design or implementation of the collaboration tool. Instead, a holistic approach is taken that gives foremost priority to the user's perspective, leading to the identification of solutions that may be implemented by different components of the software involved in performing a collaborative task.

Although the user needs and associated requirements identified in this document are not normative accessibility guidance, they may influence the evolution of future accessibility guidelines, technical specifications, or features of collaboration tools and assistive technologies. They are relevant to software developers who contribute to any of these aspects of the collaborative experience.

Introduction

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. Examples of collaboration tools include

A Web-based text editor or word processor that enables multiple authors to edit content simultaneously, with each contributor's changes being integrated into the resulting text and propagated in real time 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.
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.

Distinctive features of collaboration tools

This document addresses features unique to collaboration tools, rather than features which they share in common with other types of Web application or with application software in general. Indeed, any tool that has one or more of the features addressed here has the potential to benefit from consideration of the user needs and corresponding requirements elaborated in the sections that follow.

The distinctive capabilities of collaboration tools are illustrated by the examples in section . For purposes of accessibility to people with disabilities, it is important to consider how these features may be manifest in the user interface of the tool. From this perspective, the distinguishing features may be described as follows.

Real-time co-editing: A feature enabling multiple authors to edit the same content simultaneously. The changes introduced by different authors are combined in real time, 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 can perceive, in real time, the changes made by collaborators, including the location of another author's focus within the content.
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 a text 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.

Collaboration tools can differ widely in the nature of the content that may be read or edited, and in the manner in which it is presented to the user. For example, word processors provide a what you see is what you get (wysiwyg) interface based on a rendered view of the content, whereas editors designed for use with source code or markup language text do not. In the latter case, indentation and syntax highlighting may be the only visual cues to the structure of the code or markup available in the editing environment.

Collaboration tools that support editing of graphics, 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 these types of content are not considered, as they are separate problems from the user needs associated with the collaborative features of the tools.

Collaboration tools and accessibility

By following established guidance such as that of Web Content Accessibility Guidelines (WCAG) [[wcag21]], designers of collaboration tools can ensure that their user interfaces are perceivable to and operable by a wide range of users with disabilities. However, implementing current guidelines is not sufficient by itself to ensure that such a user interface is understandable, or that it can be used efficiently to complete collaborative tasks.

The collaboration-related features of these tools can impose significant cognitive demands on the user. This is especially so if a screen reader is used, and the interactive elements of the application are presented serially in speech or braille. For example, a screen reader may present details of suggested changes and comments while the user is reading a document in a word processor. Details of collaborators' activities in the document may be presented in real time. The screen reader user may also be expected to communicate with 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.

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.

Which aspects of the cognitive complexity are most challenging to a variety of users with learning or cognitive disabilities? Should we clarify further in the text that sensory disability as such (perception) is not the issue here; it is fundamentally a cognitive issue even for screen reader users (whether or not any cognitive disability is involved). Also, are there specific issues of importance to users of captions or sign language in dividing attention between communication and use of the collaboration tools?

User need definition

User needs relate to what conditions a particular application or platform must satisfy for a user with a disability to complete a task or to achieve a particular goal. User needs are dependent on the context in which an application is used, including the user's capabilities and the environmental conditions in which interaction with the interface takes place. 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.'

Real-Time co-editing

User Need 1: Users need to be able to discover the presence of collaborators who are reading or editing the content.
REQ 1: Provide a mode of operation in which status messages alert the user whenever a collaborator opens or closes an interactive session involving the same content that the user is accessing (e.g., the same document).

Status messages need to be made available to assistive technologies, including screen readers. See Web Content Accessibility Guidelines (WCAG) 2.1 [[wcag21]], success criterion 4.1.3, and the associated definition of status message.

User Need 2: A screen reader user needs to be informed in real time of changes to the content made by collaborators.
REQ 2: Provide a mode of operation in which status messages inform the screen reader user of insertions, deletions or formatting-related changes made by collaborators as they occur.
User Need 3: Screen reader users need to be able to perform reading or editing tasks without distracting status messages.
REQ 3: Provide a mode of operation in which status messages informing the user of the presence or activities of collaborators are suppressed. This may be achieved by allowing the user selectively to enable and disable specific types of status message, or all such messages, for example in screen reader or application settings.
User Need 4: A screen reader or screen magnifier user needs to follow changes introduced by a collaborator as they are made.
REQ 4: Provide a function that moves the user's insertion cursor to the location in the content at which a collaborator is editing. If there are multiple active collaborators, then multiple such commands, or a menu, should be offered.
User Need 5: Users with vision, cognitive or physical disabilities need to be able to edit content without distraction from changes introduced by collaborators.
REQ 5: Provide a mode of operation in which changes made by collaborators are not displayed while the user is inserting text.

What strategies should be used to limit the cognitive demands imposed on people with needs arising from various learning or cognitive disabilities? To what extent do they overlap with the issues raised above and discussed in the research literature, which focuses on screen reader users?

Annotations

User Need 6: A screen reader user needs to be informed of annotations (e.g., comments) associated with parts of the content, such as words, sentences or paragraphs in a document, or lines of code reviewed by a collaborator in a software development project.
REQ 6: Ensure that information about annotations is conveyed to screen readers and other assistive technologies, including the boundaries of the text to which the annotation applies, metadata associated with the annotation, and any comment text.

See Web Content Accessibility Guidelines (WCAG) 2.1 [[wcag21]], success criterion 1.3.1.

User Need 7: Screen reader users need to be able to read text without being distracted by information about annotations.
REQ 7: Provide a mode of operation in which information about annotations is suppressed. This mode may be activated, for example, by a screen reader or application setting, such as a toggle switch controlling the presence or absence of annotations.
User Need 8: A screen reader user needs to be able to navigate between annotations (from previous to next) and to obtain a navigable list of annotations (e.g., a list of comments in a word processor document or on a Web page), in order to read and respond to annotations efficiently.
REQ 8: Provide navigation functions and a means of obtaining a list of all the annotations associated with the content.
User Need 9: Screen reader users need to be able to control the amount of information presented about annotations to prevent it from becoming overwhelming while they are reading, navigating and editing content.
REQ 9: Provide options for the user to limit the amount of detail presented as each annotation is encountered. For example, it should be possible to suppress presentation of metadata, or replies to comments, or to alert the user only to the presence of the annotation without presenting the metadata or comment text.

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

Does User Need 7 also apply to some people with learning or cognitive disabilities? What additional strategies should be suggested, if any?

Version control features

Suggested changes

User Need 10: Screen reader 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).
REQ 10: Provide a mode of operation in which details of insertions, deletions and formatting changes are presented by the screen reader as the user reads the content.
User Need 11: Users with color blindness need to be able to distinguish insertions, deletions, and unaltered text effectively.
REQ 11: Use distinctions other than color to identify inserted and deleted text in the visual interface.

See Web Content Accessibility Guidelines (WCAG) 2.1 [[wcag21]], success criterion 1.4.1.

Presenting Differences Between Revisions

User Need 12: Users need to be able to compare revisions in meaningful units (words, sentences, lines, etc.), according to the nature of the content, to maximize comprehension.
REQ 12: Present differences in a manner that is appropriate to the type of content. For example, program source code should be presented with line-by-line differences, whereas documents (i.e., natural language texts) should be presented with differences shown word-by-word or sentence-by-sentence.

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 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.

User Need 13: Users who are easily distracted need to receive only notifications that are crucially important to their collaborative activity.
REQ 13: Ensure that users can choose which types of notification are delivered, and which are suppressed, according to the nature of the information conveyed.
User Need 14: Users for whom reading text is slow or difficult need information that is important to the task at hand to be clearly distinguished and prioritized.
REQ 14A: Provide a mode of operation in which notifications are short, and links to more detailed information are included. In this mode, full details are not provided in the notification. For example, a user could be notified that a comment or issue has been created, with the full text being available only via a link rather than as part of the notificational message itself.
REQ 14BIf e-mail or a similar medium is used to deliver notifications, ensure that the subject of the message clearly specifies the project, document or issue relevant to the notification.
REQ 14C If multiple notifications are provided together (e.g., in a single message), ensure that the user can sort the notifications according to reasonable preferences, for example, most recent first, or oldest first. This is applicable, for example, to a series of comments organized as threads of discussion, all delivered in a single summary message to the user.

Editor's Note: Contributing to this Document