Accessible Chatzilla IRC Client

• Summary: Adapt and/or extend the ChatZilla IRC client to be accessible
• Proposed Grantee: Gijs Kruitbosch
• Mentoring: Aaron Leventhal
• Other sponsorship: none
• Estimated start date: 2007-02-01
• Estimated end date:2007-06-30
• Requested amount: $10,000

Problem

Currently, the ChatZilla IRC client is not usable by people with disabilities. Although the user base is not as large as that of Firefox or Thunderbird, ChatZilla fills a critical niche in the Mozilla community that even newsgroups and forums cannot. It is used as a 24 hour meeting place, where community members strike up relationships help each other solve problems, and engage in lively discussions. IRC is used development and support in all major open source projects. Community members often ask each other to meet on IRC, for those times that a true discussion is necessary. Even W3C standardization meetings depend on IRC for the live minuting of discussions. IRC brings a disparate worldwide open source community closer in a friendly, personal way.

Chat is here to stay. As the web becomes increasingly community based it is a primary, important means of commnication -- it is used more than the telephone in some technology development communities. Furthermore, to achieve true long term accessibility, open source communities need some contributors, who themselves have disabilities, to be as deeply involved as non-disabled contributors.

Therefore, for true inclusion and sustainable accessibility in open source communities, a quality chat solution is necessary.

Currently, there are no real choices when using IRC in an accessible way. The leading AT vendors have focused on creating some level of support for mIRC on Windows, and beyond that there is little to speak of. A good, accessible and cross-platform IRC client is needed to provide both its users and developers with an alternative to mIRC.

Challenges

Today there is no standard today for exposing a region with continuous scrolling updates, or a live buddy list with properties on each individual such as away, idle, etc. Therefore when an application wants to expose the region there is no clear way. Assistive technologies then must script each application, and may not have the information they need to do so. Therefore, this project will work with the API harmonization effort for ATK, IAccesible2 and ARIA to produce standards for handling these kinds of widgets.

It is never been straightforward how to make chat and IM applications accessible. Fortunately there is a new concept called "live regions" being in the ARIA standard which will help move things forward. The ARIA live region markup can describe the general case of regions in a user interface or web page which have meaningful changes that a user may wish to track. However, useable chat requires special navigation and reading features, and is therefore a highly specific use case with its own needs. There is further markup in ARIA, which allows a chat log to be described as role="wairole:log". Propagating the semantics of all this new markup into desktop accessibility APIs should allow chat windows to be automatically recognized. In addition, because the model and view is essentially the same in all IM and chat clients, whether desktop- or web- based, it is reasonable that a standard for exposing these widgets will successfully allow ATs to recognize and deal with them. What's needed is a fully implemented chat application which uses the markup, and one or more ATs to utilize it. This will help prove whether the standards are currently enough, or need to be further evolved (or at least clarified). The technology developed can be further utilized to help make othe rismilar widgets, such as error logs or game tracking logs, equally accessible.

True usability for chat requires the implementation of special navigation commands. Several things which are natural for sighted people are difficult for screen reader users without additional commands being available. For example, it seems natural that if you are having multiple conversations, you don't reread an entire conversation when you switch between them. Accessibility tools won't understand this without a lot of nudging in the right direction. Even worse is that updating to include new content is hard for accessibility tools - sighted people will realize someone has sent them a message, even while they're typing their own. Accessibility tools cannot magically understand this, and will need some help in only reading the things they are 'supposed to' read, at the right times.

A problem mostly specific to IRC is that it is designed for group chat. This means multiple conversations may be going on in one channel. A sighted person can scan nicknames of people sending messages, so as to filter the output. Doing this with an accessibility tool will require more effort. Yet it is important, because if users can't filter properly, they will in some cases simply be overwhelmed by the amount of messages received.

To help with the special problems of IRC and group chat, a combination of log-specific verbosity settings and navigation commands is necessary. For example, some of the following ideas were taken from T.V. Raman, the developer of EmacSpeak, in a discussion on mozilla.dev.accessibility:

1. Messages should be able to be spoken even if the current window is not active.
2. The combination of "automatically speak messages" and "selectively turn off buddies" needs to be customizable together; as an example, an alternative work habit might be to turn off auto speaking of *all* messages, and selectively turn on special buddies.
3. In all cases, it is desirable to have an auditory alert as a message comes in (separate from speaking the message)
4. The user needs a global keyboard shortcut to jump to the last buddy who talked to you and that you haven't responded yet.
5. In general the above navigation commands works off of the ring of pending buddies, pushing the buddy you just jumped to the end of the queue.
6. Finally, the user needs a means of quickly finding out all the buddies who have sent a message to the user while they were AFK

Benefits

There are numerous benefits in doing this work:

1. Applications with chat, instant messenger or any kind of log (error log, game play log, etc.) will now be able to expose their UI in a consistent way, and reuse any screen reader logic developed for chat
2. Assistive technologies will now be able to make these kinds of applications without per-application scripts or hacks.
3. It becomes easier for visually impaired users to use IRC
4. The barrier to entry for visually impaired developers working on Mozilla and other open source and open standards projects is significantly lowered, given that IRC is an important resource for developers. To achieve true long term accessibility, we need contributors with disabilities to be as deeply involved as non-disabled contributors.
5. Sighted users get the ability to use text to speech functionality. This increases the usefulness of chat as a background task.
6. Further exercise the XUL toolkit, authoring guidelines and checking tool, as well as in ARIA (previously known as DHTML accessibility).
7. Add Gijs as a resource to the other accessibility developers who are less experienced with the XUL toolkit. Gijs understands the details of developing XUL applications and can help other developers working on extensions, Thunderbird and Firefox accessibility.
8. By investing in Gijs, we will end up with a developer who understands both XUL and accessibility. This comes at a time when this is even more needed due to the loss of Mark Pilgrim to non-Mozilla work (he previously owned accessibility in the Firefox chrome), and the sudden gap in that critical area.

Work Plan and Deliverables

Gijs will:

• Work together with the Mozilla community to help define the ideal end user solution for chat, and any specific techniques which can be used to arrive at that experience.
• Specifically work with Peter Thiessen, a University of Toronto student working on an accessible AJAX chat for a Masters degree project. The same techniques and technologies should be used with both, and combining resources should help both projects. In fact, both projects will likely end up using ARIA markup to expose that chat log and buddy list.
• Look at the support existing accessibility tools have for other chat clients (such as MSN messenger and mIRC), as well as asking users of such accessibility tools what their problems with these applications are, and how they think this could be improved.
• Make sure at least one AT provider's tools can be used with ChatZilla, both in Firefox and standalone on XULRunner (and if possible, as part of the SeaMonkey Suite). This will at least involve:
  • Going back to content-type docshells (as opposed to type="chrome" browsers, which, as a side effect, turn off accessibility for that viewport).
  • Improve keyboard navigation in the current UI.
  • Finish work on 'filters' for IRC messages. This will give people very fine-grained control over what messages they feel are important, and want to be notified of (by sounds or other means of drawing attention).
  • Some reworking of the internal structure of the ChatZilla chat output, to make sure accessibility tools read the right things. Use of ARIA markup such as role="wairole:log", aaa:live="assertive" on the chat log, aaa:atomic="true" on each message and aaa:datatype on the timestamp may be desirable
  • Recommend changes to accessibility APIs such as IAccessible2, ATK/AT-SPI and ARIA so that all the necessary semantics are exposed
  • Cooperation with AT vendors and other people working in this area, so as to assure that what we use is supportable by major vendors, and reusable by other chat programs.
• Start using Charles Chen's Fire Vox libraries, either in ChatZilla itself or as an extension or ChatZilla plugin. This will allow even more fine-grained control over what gets read aloud and what doesn't. This could also be a feature for sighted users, to have messages with their name read aloud if the window is minimized, for example. Possibly work directly in Fire Vox with Charles Chen and Peter Thiessen to support the navigation commands described in the Challenges section.
• Possibly make modifications to the underlying accessibility framework in Firefox, where it doesn't meet the needs of the project, in addition to working with AT manufacturers in reporting problems and finding workarounds.
• Make sure ChatZilla complies with the Accessible XUL authoring guidelines and/or the new guidelines WebAIM is working on. Possibly run the Chatzilla UI through the WebAIM XUL accessibility checker, if that is ready.
• Write documentation on how any kind of 'chat' or log is made accessible, how the accessibility tools use this, and how other accessibility tools and chat programs could implement this.

Experience

Gijs has been involved with the Mozilla project in general, and ChatZilla in particular, for over 2 years now. He knows his way around the community, how to use the available tools (LXR, Bonsai, Tinderbox, etc.) and where to ask for help if he runs into problems. He has also participated in the 2006 Google Summer of Code, in which he worked on the JavaScript debugger Venkman as well as Joe Hewitt's Firebug (as well as some backend issues relevant to both). He's had CVS commit access for about a year now. See also this list of fixed Mozilla bugs.

While well-versed in ChatZilla and XUL, Gijs has no previous experience in working in the accessibility field. He will, however, be doing a Minor program in the field of Social Information Science at the University of Amsterdam (in addition to pursuing a Major in Artificial Intelligence there). The Social Information Science program deals with knowledge representation and human-computer interaction, a field closely related to accessibility.

Success criteria

The project's success shall be assessed by checking:

• ChatZilla works well with at least one accessibility tool, which provides navigation and message reading modes that are helpful in the task of tracking the desired conversation(s) when there are several going on at the same time.
• AT vendors of products that don't work well with ChatZilla yet have been informed of this, and the fact that it does expose the necessary information (and that it works with (some) other tool(s)).
• ChatZilla complies with the accessible XUL authoring guidelines
• ChatZilla allows both visually impaired and sighted people fine-grained control about what messages they think are important, and how ChatZilla reacts to such messages.
• Documentation has been delivered on how to make chat programs in general accessible.
• If applicable, a report on how accessibility APIs need to be augmented so as to (better) support chat applications.

Summary

In summary, Gijs will try to make ChatZilla accessible and easily usable by both the visually impaired and sighted users. Doing so will improve accessibility of IRC in general across platforms, and will further the Mozilla Foundation's mission of promoting choice and innovation on the internet. It will also make Mozilla's own community, and open source communities in general, more accessible to the visually impaired.