User:GijsKruitbosch/ChatA11Y AppAuthors

Many chat solutions these days are web-technology-based. In this case, we are not just speaking about web-based chat solutions like Mibbit, Meebo, AIM Express, MSN Web Messenger, etc., but even about client-side applications like Adium, Google Talk, and so on. Even these client-side applications use web technology in order to achieve what they need to do (and in fact, some IM protocols use HTML to transfer richly formatted text and so on).

In order to make such applications or websites accessible to the blind and visually impaired, authors can make use of ARIA markup to signify the function of elements of the page or application. In particular, they can indicate which part of an HTML document is a (chat) log, and prioritize messages inside this log. In the remainder of this document I will first detail the relevant markup, and then provide some concrete examples from Mozilla Live Chat, and ChatZilla.

ARIA markup for chat logs

The WAI-ARIA specification allows web authors to specify the functionality of parts of a page in a way that does not affect the visual properties of the page or its elements. Accessibility tools, such as screenreaders, can make use of this information in order to provide better access to users. For example, if a <span> is really a button, the author can use role="button" to indicate that this particular span is actually meant to be a button, and a screenreader will then present this element as a button rather than a piece of text on the page (as it would normally do for a span). This enables the user to interact with it in a way they would normally interact with a button, just as a sighted user would normally be able to do (assuming the span in question looked like a button in some obvious way).

By specifying various ARIA attributes, we can thus instruct the Assistive Technology software on what we mean. I will introduce each of the attributes relevant for chat logs in the following subsections.

role="log"

In the case of chat, there is a particular role that may be used: log. Once you specify this (using the attribute role="log"), the AT software knows that it is a log of some kind. In principle this could be any kind of log (console output, for example, or an error log from a server operation, could also qualify). You can use it on different tags: ChatZilla uses it on a <table> in which it outputs chat messages, Mozilla Live Chat uses it on a <div>.

Implicitly, assigning this role to an element will cause the AT software to consider your element as a live region. A live region is a part of the page in which the AT should expect elements to be added or removed, and the text nodes inside the element to be changed as well. In particular, for a log, the AT is supposed to assume that:

• the information is logically sequenced.
• the information is added to the end of the log.
• the information ought to be announced at a default politeness level of 'polite' (see next section).

aria-live

The aria-live attribute can be used to indicate a politeness level. The concept of a politeness level is there to be able to indicate the priority of messages. Sighted humans have the comfortable ability to scan a range of visual information without going to the trouble of actually reading and understanding it all. For example, if you ask a question in a multi-user chatgroup to one specific person, you ignore other people's messages without reading all of them. Because this is not possible for users of AT tools, we need to provide some information to the AT as to how important the information is, in other words, how polite it should be about interrupting the user's work with it. Error messages about the connection to the server may be more important than messages from the contact with whom the user is talking, for example.

ARIA knows 3 levels of politeness:

• off
• polite
• assertive

off does what it says on the tin.

polite is the default, and AT software should announce those messages without interrupting the user.

assertive is to be used for more important messages, for which the AT software should interrupt the user.

The default for role="log" elements is polite, but you may change this by adding an attribute to the element, eg. aria-polite="assertive". Furthermore, you can add such attributes to individual messages, so you could specify aria-polite="polite" on the log, but for some individual messages (eg. connection errors, or in multi-user rooms, messages that mention your name) you could then specify aria-polite="assertive" in order to emphasise them.

aria-relevant

In some cases, messages might be removed from a chat log (ie we might not keep them forever). We may not necessarily want those removals to be announced. In order to allow applications to specify what changes to a live region need to be announced, ARIA has an aria-relevant attribute. This is a space-separated list of one or more of:

• additions
• removals
• text

(the list may also be empty)

The aditions and removals keywords indicate that adding respectively removing elements should be announced.

The text keyword indicates that changes in the text inside an element should be announced.

The default value for this attribute is aria-relevant="additions text".

For a chatlog where we add messages but do not change them, and where removals are relevant, we could thus specify: aria-relevant="additions removals".

Example: Mozilla Live Chat

Mozilla's support website offers realtime chat in case of problems which cannot be solved by the extensive written documentation available online. This chat was made accessible.

The chat works by having a single div container to which divs get appended for each message received and sent:

    <div id="ytext" role="log" aria-live="off">
    </div>

The div container has a role="log" attribute to indicate it is a live region. It has an aria-live="off" attribute to prevent messages from the user themselves being announced back (as this would be annoying - they get added client-side, so there is no guarantee they were received in case of network issues, so adding them would not provide any information). We do not care about removals, so there is no need to add an aria-relevant attribute, as the default is fine.

The logic for adding messages then looks like this (simplified from the original):

 var chatLineDiv = document.createElement("div");
 if (isAnnouncement) {
   chatLineDiv.setAttribute("aria-live", "assertive");
 }
 var fromIsCurrentUser = false;
 if (! isAnnouncement) {
   // is the from the same as the current user?
   fromIsCurrentUser = (nickname == from);
   if (!fromIsCurrentUser) {
     chatLineDiv.setAttribute("aria-live", "assertive");
   }
 }

So, each message is marked with aria-live="assertive" if it is either an announcement, or if it was not sent by the current user, thus making sure these messages are announced by the accessibility tool.

Example: ChatZilla

In ChatZilla's default output window, a table is present in which all the messages get added as rows:

 <table aria-live="polite" role="log" class="msg-table"></table>

In this case, we opted for simply having all messages spoken. Things which are sent by the user might not necessarily end up in the output window in the same way (eg. multiline messages would be split).

For each message that is added and that is more important than other messages (either because it is a message intended for you directly, rather than a channel, or a channel message containing the user's nickname name, or a word the user specified in their stalk list), the message row is marked with aria-live="assertive" rather than polite (the default for the message table, as shown above). This allows important messages to come to the user's attention before other messages (see the explanation about aria-live values noted above).

Tables or Divs for messages

One of these examples used a div container for the messages, with one div added for each messages, while another used a table with rows for each message. In principle both can be made accessible using ARIA, as shown above.

If you have not yet made a decision as to which to use for your application, the advantage of tables for assistive technology users is that they allow one to easily navigate just the timestamps, just the users or just the messages (without reading the other columns). In a div, even if you have each part in a separate span (which would be visually styled so as to be significantly different for sighted users), these parts quickly become jumbled together due to the way accessibility tools work, thus taking away useful navigational possibilities.

Conclusion

This article has attempted to show how to make chat logs accessible using the WAI ARIA spec. If you have any further questions, drop by #accessibility, and people might be able to help.