RESNA 27th International Annual Confence
A-Communicator: Towards Accessible Whiteboarding
The A-Communicator is introduced; AComm is an instant messenger designed for accessibility. In addition to typical features, it also contains a Whiteboard - a synchronous drawing area allowing users to draw two-dimensional figures. AComm implements several features to improve accessibility; These include developments from previous text-based chat programs and full keyboard accessibility. Most notably, however, is the inclusion of a novel component for the description of whiteboard objects, Peer Description. This component is a light-weight addition by which the task of describing whiteboard objects may be undertaken by a single user, or shared between several. The addition of descriptions to a whiteboard results in improved accessibility for a user with visual disabilities, and also a means of augmenting the whiteboard tool for general users. A demonstration of an alpha version of AComm will be presented.
A-Communicator, Instant Messenger, Whiteboard, Accessibility, Peer Description
With the growing popularity of synchronous communication tools, there exists a need for associated accessible tools. This is especially true for the domain of Instant Messaging, its fastest growing sub-field. Instant Messengers include software and protocols such as ICQ, Microsoft Messenger and Jabber, all of which are very quickly gaining in popularity. In a study by the Radicati Group, it was estimated that there exists 590 million IM account currently active, a number which is expected to double by 2007 [1]. Additionally, there is a growing trend amongst synchronous communication tools to include a component for synchronous drawing; A whiteboard is a two-dimensional drawing area, on which users may typically draw free-hand lines, text and geometric shapes, similar to simple “paint” programs. Amtmann et al. note that current whiteboards are largely inaccessible, and “the best way to accommodate users of screen readers is to avoid using Whiteboards exclusively for content that is essential and significant” [2] - as their popularity grows, it is clear that this will not be a possibility.
Much progress has been made in terms of improving the accessibility of text-based synchronous chat. An example of such a program is A-Chat 1 , developed by the ATRC. In improving accessibility, A-Chat utitlized such strategies as keyboard short-cuts, configurable functionality and appearance, and a means by which automatic functionality may be disabled in favour of manual control and audio-prompts. However, with the rising popularity of drawing tools, accommodating only text-based chat is quickly becoming insufficient for business and academic settings.
A-Communicator (hereafter, AComm ) is a first attempt at the creation of an accessible Instant Messenger ( IM ) client including a whiteboard. At its top level, AComm is designed to provide all the typical functionality of a common IM client, without sacrificing ease-of-use for experienced users. The Instant Messenger component 2 has been built using Jabber, an open-source and highly popular protocol [3].
AComm is built using Java Swing, and hence inherits the associated accessibility features for accessing the UI. In addition, AComm implements the same features for text-chat as does the A-Chat; That is, AComm implements keyboard shortcuts, optional over-rides for automatic processes (allowing users to turn off features which might steal focus from a screen-reader), and helpful sound prompts. AComm thus serves as a viable tool for text-based IM functioning, including private and group chat.
In addition, AComm contains a whiteboard 3 , by default hidden. The whiteboard operates in typical fashion (in terms of mouse-driven accessibility), and may be used to import/export SVG code, or to create new drawings. Users may draw and manipulate objects (freehand and straight lines, rectangles, ellipses, text); The objects appear not only on the whiteboard, but also are represented by an automatically-generated name in a combo box immediately underneath. Objects may be selected through a pointer tool using the mouse, or may be selected by selecting the appropriate name from the combo box, and once selected, may be moved or deleted. Aggregate changes to the whiteboard appear in the text-chat area as “system” messages, e.g. “John clears the whiteboard”.
Directly underneath the whiteboard is a description area; This area contains a list of all un-described whiteboard objects. The idea here is that anyone involved in the chat may select an object from the list and describe it, or remove it from the list having decided that a description is unnecessary. To describe, a user will “lock” an object in the description list, thereby activating a text area underneath. The user may then enter a description and submit it, delete the description, or “unlock”, allowing another user to perform a description. Hence, for each and every whiteboard object, any chat user may enter the description. The task of providing descriptions may be undertaken by a single user throughout the chat, or shared by all users equally.
When an object on the whiteboard is described, that description is placed into both the text chat as a “system” message (e.g. “Sara draws Line 1: the y-axis”), and is included along side the object name in the combo box. Hence, a user using only the text chat will receive messages regarding all described objects at the time of description, and will additionally be able to access the descriptions by cycling through the combo box. Once an object has been described, all modifications are also sent to the text-chat as “system” messages (e.g. “John deletes Line 1: the y-axis”).
In addition, there exists a mechanism by which objects on the whiteboard may be grouped - a user may select several objects and select the “group” (or undo with the “ungroup”) option. In this case, a single description is associated with all objects, and the group occupies only one slot in the combo box. If descriptions exist for some of the objects, the first is automatically chosen as the description of the group, except in the case of a text object existing in the group; In that case the content of the text forms the description. In this manner, a text label associated with a set of objects automatically forms the description. Figure One shows the AComm system engaged in a chat. In the foreground is the private chat window, with the text-chat area on the left and the whiteboard area on the right. The Description area is at the bottom right. In the background is the Roster window.
The peer description approach then serves two purposes: Firstly, to place accessible descriptions into areas of the UI which may be accessed by a screen reader (into the text-chat and the combo box); Secondly, it provides a mechanism by which groups of objects may be described as a whole, thus enhancing whiteboard functionality for all users. It is expected that users with visual disabilities will not activate the whiteboard portion of the chat window, thus receiving the descriptions of objects as a part of the text-chat, allowing them some access to the information there contained.
In addition to keyboard accessibility for all navigation and chat functions, AComm includes keyboard accessible drawing functionality. These keyboard shortcuts allow keyboard users to (relatively) quickly place, move and resize any of the drawn objects, with the exception of the freehand tool.
A-Comm makes progress towards being an accessible whiteboard-enabled collaborative tool. Peer Description is a lightweight, but effective means of increasing the accessibility of a whiteboard, without requiring a dedicated user for producing descriptions. This development not only offers a way in for users with visual disabilities, but also as a means of grouping and providing additional cues to all users. Also, the keyboard accessible controls allow users without mouse access to participate in the drawing process.
AComm is by no means the last word in accessible whiteboarding. Rather, it may be viewed as a starting point through which accessible synchronous communication may be realized. Immediate extensions to this system involve means by which the description process may be made more intelligent - at present the only automatically-generated descriptions are for text objects, where it is obvious what those descriptions ought to be. However, it is possible to augment the automatically-generated names provided for the objects, perhaps with minimal information regarding their location and intersection with other objects. Other directions for development stem from alternate ways of displaying the contents of the whiteboard. There exist many methods of communicating SVG code to users with visual disabilities; Examples include means by which SVG may be sent to an embossing printer [4], or by which an image of the SVG may be converted into a sound map [5]. Finally, there may exist means by which the UI may be improved with respect to the keyboard-access for whiteboard manipulations - is it possible to make this process less keystroke-intensive? Certainly, a configurable set of user options could help.
Funding for this project is provided by the Department of Canadian Heritage through the New Media Research Networks Fund. The authors also wish to gratefully acknowledge the University of Toronto, Mike Lam, Jutta Treviranus, and Laurel Williams for all of their work on this project.
Jan Richards,
Adaptive Technology Resource Centre,
University of Toronto
130 St. George St.,
Toronto, ON, Canada, M5S 1A5
tel.: 416.946.7060 ,
email: jan.richards@utoronto.ca