| WGBH | NCAM | SALT PROJECT | 1EdTech Consortium |

7. Guidelines for Developing Accessible Synchronous Communication and Collaboration Tools

This section will cover guidelines for the development of synchronous communication and collaboration tools including:

• synchronous text chat.
• audio-conferencing.
• video-conferencing.
• whiteboards.
• Multi-user domain Object Oriented environments (MOOS).

Synchronous communication and collaboration tools, such as synchronous text chat, audio-conferencing, video-conferencing, and whiteboards, are increasingly important components of online learning. In order to ensure the full participation of learners with disabilities, these synchronous tools must be made accessible to them. In general, this means ensuring that the user interface of the tool, as well as the real-time communication managed by the tool, are both accessible, for input and output equally.

7.1 Synchronous Text Chat

Synchronous text chat tools (such as internet relay chat (IRC), ICQ, and others) allow two or more users to communicate via typed text messages in real-time. For a chat tool to be accessible, both the navigation system and the messages themselves must be accessible.

Common synchronous text chat accessibility problems include:

• complex and non-standard user interfaces.
• some exclusively mouse-driven functions.
• need for simultaneous user attention to multiple areas (i.e., message composition and message monitoring).
• fast pace of conversation may limit access by users who communicate slowly.

Learning system developers may enhance the accessibility of synchronous text chat applications for all users by following these practices:

• Simplify the user interface and follow appropriate platform-specific user interface guidelines.
• Provide help files, including an accessible orientation to the interface and its functionality.
• Ensure that all mouse actions can also be completed, effectively, from the keyboard.
• Provide keyboard accessible mechanisms to enable the user to quickly shift the focus between the message composition and the message monitoring areas.
• Provide the choice not to automatically move focus to new messages as they arrive.
• Provide an option to manually refresh the list of messages.
• Provide mechanisms that allow users who communicate slowly to participate effectively (e.g., speaker designation).

7.2 Audio-Conferencing

Audio-conferencing (via phone or Internet) allows two or more users to collaborate via real-time speech. In order to have access, users with hearing and speech disabilities must be accommodated by the system.

Common audio-conferencing accessibility problems include:

• audio output that is inaccessible to users who are deaf or who have profound hearing loss.
• speech input that may be difficult for users with speech disabilities.
• some exclusively mouse-driven functions.
• fast pace of conversation that may limit access by users who communicate slowly.

Learning system developers may enhance the accessibility audio-conferencing applications for all users by following these practices:

• Ensure that a real-time text transcript is available to participants. The transcript can be provided by any one of a number of methods (e.g., generated by effective minute taking, telecom relay service, or reliable voice recognition).
• Ensure a real-time text-to-speech capability is available to participants via telecom relay service or automated text-to-speech.
• Ensure that all mouse actions can also be completed, effectively, from the keyboard.
• Provide mechanisms that allow users who communicate slowly to participate effectively (e.g., speaker designation).

7.3 Video-Conferencing

Video-conferencing allows two or more users to collaborate via real-time interaction that includes both video and sound. In order to be accessible, users with visual, hearing, and/or speech disabilities must be accommodated.

Common video-conferencing accessibility problems include:

• additional visual information such as graphs and charts that may be inaccessible to users who are visually impaired.
• audio output that is inaccessible to users who are deaf or who have profound hearing loss.
• speech input requirements that may be difficult for users with speech disabilities.
• videoconference systems that preferentially encode stationary elements of a scene, rather than dynamic ones. These automated choices can disrupt effective transmission of sign languages, since they depend on movement.
• some exclusively mouse-driven functions.
• fast pace of conversation that may limit access by users who communicate slowly.

Learning system developers may enhance the accessibility of video conferencing applications for all users by following these practices:

• Provide a mechanism for describing visual support elements and encourage the use of this function.
• Ensure that a real-time text transcript can be made available to participants. These transcripts can be generated by effective minute taking, telecom relay service, or reliable voice recognition. Once generated, this text transcript might be displayed by a sign language "avatar" (computer-generated signer). Real-time text transcription services can be accessed remotely.
• Enable the addition of sign translation services provided remotely. The tool should be designed to accept a second video stream arriving from another location.
• Ensure that a real-time text-to-speech capability is available to participants. Transcripts can be generated by a telecom relay service or automated text-to-speech software.
• Investigate video encoding standards that facilitate sign language transmission, such as MPEG-4.
• Ensure that all mouse actions can also be completed, effectively, from the keyboard.
• Provide mechanisms that allow users who communicate slowly to participate effectively (e.g., speaker designation).

7.4 Whiteboards

Whiteboards are the graphical equivalent of synchronous chat tools. They allow multiple users to work on collaborative drawings in real-time. They often include functionality for drawing, painting and importing existing graphic files. In order for the system be accessible, both the navigation system and the content of the workspace must be accessible.

Common whiteboard accessibility problems include:

• exclusively graphical workspace that is inaccessible to people with visual disabilities.
• when text tools are available, they often produce text in such a way that it is not accessible by screen readers.
• many exclusively mouse-driven functions.

Learning system developers may enhance the accessibility of whiteboard applications for all users by following these practices:

• Integrate an accessible synchronous text chat with the whiteboard and encourage users to use this function to describe their graphical work.
• Ensure that all mouse actions can also be completed, effectively, from the keyboard.
• Implement the workspace using SVG in order to take advantage of the access features of this markup language (see subsection 4.3.3 on Scalable Vector Graphics).

The access features of the SVG language include:

• SVG images are represented as objects, so lines stay sharp when magnified.
• SVG objects may labeled. Also objects can be grouped hierarchically. The hierarchical structure of these text equivalents works better than a single text description to convey fine-grained detail.
• SVG supports stylesheets, DOM2 for customizing presentation and Meta-data and RDF for efficient cataloguing.
• SVG supports device-independent events so operation is not limited to the mouse.

7.5 Multi-User Domain Object Oriented Environments (MOOs)

MOOs are multi-user virtual environments in which users often control "avatars" (computer-generated actors) that move through the virtual world, interacting and communicating via speech generated from user-typed instructions. In order to be accessible, both the environment navigation system and the communicative exchanges between avatars must be accessible.

Common MOO accessibility problems include:

• visual information in the MOO, including the appearance of the physical environment and the other avatars, cannot be accessed by users who are blind.
• audio output is inaccessible to users who are deaf or who have profound hearing loss.
• some exclusively mouse-driven functions.
• complex spatial navigation of the MOO.
• fast pace of conversation may limit access by users who communicate slowly.

Learning system developers may enhance the accessibility of MOOs for all users by following these practices:

• Provide a mechanism for automated text description of the virtual world.
• Ensure a real-time text transcript can be made available to participants. This text transcript might be translated into Braille or even (from the listener's perspective only) signed by a speaking avatar.
• Ensure that all mouse actions can also be completed, effectively, from the keyboard.
• Include powerful navigation tools for accomplishing high-level navigational instructions (e.g., "take me to the library").
• Provide mechanisms that allow users who communicate slowly to participate effectively (e.g., speaker designation).

Resources:

• Center for Applied Special Technologies (CAST)
• Equal Access to Software and Information (EASI)
• Special Needs Opportunity Windows (SNOW)
• University of Washington DO-IT Program
• The CPB/WGBH National Center for Accessible Media (NCAM)

NEXT | CONTENTS