live regions as a solution for web 2.0 accessibility

This article was downloaded by: [University of California, Riverside Libraries]On: 17 October 2014, At: 21:37Publisher: RoutledgeInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Journal of Access ServicesPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/wjas20

Live Regions as a Solution for Web 2.0AccessibilityPeter Thiessen a & Jutta Treviranus aa University of Toronto, Adaptive Technology Centre ,Published online: 12 Jan 2010.

To cite this article: Peter Thiessen & Jutta Treviranus (2010) Live Regions as a Solution for Web 2.0Accessibility, Journal of Access Services, 7:1, 15-32, DOI: 10.1080/15367960903385813

To link to this article: http://dx.doi.org/10.1080/15367960903385813

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoever orhowsoever caused arising directly or indirectly in connection with, in relation to or arisingout of the use of the Content.

This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/wjas20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/15367960903385813

http://dx.doi.org/10.1080/15367960903385813

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

Journal of Access Services, 7:15–32, 2010Copyright © Taylor & Francis Group, LLCISSN: 1536-7967 print / 1536-7975 onlineDOI: 10.1080/15367960903385813

Live Regions as a Solution for Web 2.0Accessibility

PETER THIESSEN and JUTTA TREVIRANUSUniversity of Toronto, Adaptive Technology Centre

Web 2.0 applications now include desktop-like User Interfaces (UI),with behavior such as the ability to dynamically update a region ofa Web page, drag and drop elements, and dramatically improvedapplication responsiveness. Unfortunately, accompanying this ex-citing new functionality a number of accessibility challenges havebeen identified. Most issues involve exposing a combination of dy-namic updates via Asynchronous JavaScript and XML (AJAX), Dy-namic HTML (DHTML), and semantics. Assistive Technologies (AT)can no longer employ conventional strategies to access informa-tion updates in a Web system. The solution to the AJAX accessibilityproblem is a relatively new specification called the Web Accessibil-ity Initiative-Accessible Rich Internet Applications (WAI-ARIA). LiveRegions, part of the ARIA specification, defines how to expose Doc-ument Object Model (DOM) updates in a way meaningful to AT.The aim of this article is to introduce the Live Region syntax andseveral identified issues and changes to the WAI-ARIA specification,and als, to demonstrate how Live Regions can be implemented asan accessible Web 2.0 solution through a use case, ReefChat.

KEYWORDS Accessibility, Web 2.0, AJAX, ARIA, Live Regions, useragents, human factors, design

INTRODUCTION

Web applications such as Google Maps (Google, n.d.b) and Flickr (Yahoo!,n.d.a) demonstrate the power of AJAX Web systems. A quick look at GoogleMaps, for example, reveals that a Web application can now have a draggable

Address correspondence to Peter Thiessen, University of Toronto, Adaptive Technol-ogy Centre, 130 St. George St., Toronto, Ontario, Canada M5S 1A5. E-mail: [email protected]

15

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

16 P. Thiessen and J. Treviranus

map that can update in the background as users zoom in and out by scrollinga mouse. However, without the appropriate semantic information, it is notpossible for AT to determine how to handle this new interactive functionality.

Traditionally, AT, such as screen readers, which utilize text-to-speechand Braille displays, have treated information on a Web page as content thatcan be linearized. All new content obtains focus and is spoken. AJAX Webapplications problematize this assumption; new content can appear in arbi-trary locations, and user interactions within the page are far more complex.Since these AJAX Web applications behave more like desktop applicationsthan Web pages, solutions for making desktop applications accessible can beapplied to these AJAX Web applications. One important aspect is to informusers of important events that are occurring on parts of the screen, even ifthose parts are not focused.

In current desktop applications, there is a set of known widgets such asbuttons, trees, data cells, etc. These widgets behave in a predictable manner;thus, an AT simply needs to know how to support the events of a type ofwidget in order to provide reasonable support for any instance of that typeof widget. However, AJAX applications do not share this uniformity. ManyAJAX applications use custom widgets created out of span and div elements,mixed with input elements and graphics, and laid out by Cascading StyleSheets (CSS). Sometimes, AJAX applications will even use custom widgets forstandard HTML widgets such as a button because the application developerwishes to change the behavior and/or appearance of the widget to fit theparticular application better. As a result, while AT can pick up DocumentObject Model (DOM) mutation events, it is very difficult, if not impossible,for an AT to understand what that event represents in the context of an AJAXapplication.

Currently the WAI-ARIA (W3C, 2009) specification addresses the prob-lem of dynamic Web content by embedding accessible roles and states intoHTML documents. Using ARIA, Web authors can create custom widgets suchas a slider or grid and make them accessible by marking them up with WAI-ARIA. The markup allows a mapping for behavior and semantics that AT caninterpret and speak to the user. One particular part of ARIA that will be thefocus of this article is Live Regions (Mozilla Developer Center, n.d.).

In the past, a Web page change could only be spoken in entirety, whichoften annoyed a user, or by speaking very little or not at all, making someor all information inaccessible. Until recently, AT have not been able toimprove this because no standardized markup existed to alert the AT of achange. Live Regions fill this gap and provide settings that can be used tonotify an AT about a DOM change. Settings include where and when theupdate occurred and how important it is. The goal in using Live Regionsis to provide the most relevant information first and limit the amount oftrivial information. Web developers should familiarize themselves with ARIAand Live Regions and plan accessibility into Web 2.0 projects; otherwise,

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 17

a significant user group will be left out along with the potentially relatedmonetization possibilities (W3C Web Accessibility Initiative, n.d.).

In a previous article, “ARIA Live Regions—An Introduction to Channels”(Thiessen & Chen, 2008) ARIA channels were introduced. This article ismeant as a follow-up on recent changes in the ARIA syntax, related work,and to provide a practical example of how to implement Live Regions.

The organization of this article is as follows: In the next section, we de-scribe the markup for ARIA Live Regions. In following sections, we describeseveral issues found in the specification, such as a changing syntax and de-termining causality; we demonstrate ARIA Live Regions in action throughReefChat (ReefChat, n.d.); we have a discussion about the decisions madein ReefChat and future work; and we discuss related work, followed by aconclusion.

WAI-ARIA LIVE REGION MARKUP

The solution to dynamic Web 2.0 content is to mark up the dynamic regionswith ARIA Live Regions. Live regions are only one part of ARIA; other partsenable desktop-style JavaScript widgets, specifying type restrictions on data,or marking up regions of a page with landmarks (such as the main content).The ARIA specification can be broken down into ARIA-ROLE (W3C, 2006)and ARIA-STATE (Thiessen & Chen, 2008). State is the most important andenables XML languages to add information about the behavior of elements.

The ARIA specifications suggest adding markup to the live regions ofa document to help solve the issue of what should be done with DOMmutation events. By looking at the markup of a live region, an AT canact intelligently when DOM mutation events are fired for that region. Thefollowing subsections present the properties for live regions.

Note that ARIA channels were recently removed from the specificationto reduce complexity.

aria-live=POLITENESS SETTING

aria-live=POLITENESS SETTING is used to set the priority with which ATshould treat updates to live regions. These are only the default prioritysettings for live regions; AT may provide ways for users to override/changethese priority settings.

Note that in Table 1 the aria-live=“rude” politeness setting was recentlyremoved by the W3C WAI to reduce complexity.

aria-relevant=LIST OF CHANGES

aria-relevant=[LIST OF CHANGES] in Table 2 is used to set what types ofchanges are relevant to a live region. Multiple types of changes can be

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


TABLE 1 aria-live=[POLITENESS SETTING]

Setting Description

aria-live=“off” This is the default. Any updates made to it should notbe announced to the user. Live=“off” would be asensible setting for things that update very frequentlysuch as timers that change every second.

aria-live=“polite” The region is live, but updates made to it should only beannounced if the user is not currently doing anything.Aria-live=“polite” should be used in most situationsinvolving live regions that present new information tousers, such as updating news headlines.

aria-live=“assertive” The region is live. Updates made to it are importantenough to be announced to the user as soon aspossible, but it is not necessary to immediatelyinterrupt the user. Aria-live=“assertive” should beused if there is information that a user should knowabout right away, for example, warning messages in aform that does validation on the fly.

listed as relevant; the types are separated by a space. The default is aria-relevant=“additions text.”

aria-atomic=BOOLEAN

aria-atomic=BOOLEAN in Table 3 is used to set whether or not the ATshould present the live region as a whole. The default setting for aria-atomicis false. AT may provide ways for users to override whether or not the liveregion is treated as atomic.

aria-labelledby=IDLIST

aria-labelledby=[IDLIST] in Table 4 is used to associate a region with itslabels.

TABLE 2 aria-relevant=[LIST OF CHANGES]

Setting Description

aria-relevant=“additions” aria-relevant=“additions” states that the insertion ofnodes to the live region should be considered relevant.

aria-relevant=“removals” aria-relevant=“removals” states that the removal ofnodes from the live region should be consideredrelevant.

aria-relevant=“text” aria-relevant=“text” states that changes to the text ofnodes that already exist in the live region should beconsidered relevant.

aria-relevant=“all” aria-relevant=“all” states that all changes to the liveregion should be considered relevant. This is the sameas doing aria-relevant=“additions removals text.”

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 19

TABLE 3 aria-atomic=[BOOLEAN]

Setting Description

aria-atomic=“false” This is the default. It means that when there is a change in theregion, that change can be presented on its own; the ATshould not present the entire region. aria- atomic=“false” isgenerally a good idea, as it presents users with only changesand does not cause them to hear repetitive information thathas not changed. However, Web developers should take carethat the changed information, when presented by itself, canstill be understood and contextualized by the user.

aria-atomic=“true” If atomic is set to “true,” it means that the region must bepresented as a whole; when there is a change, the AT shouldpresent the entire region, not just the change.aria-atomic=“true” can make it harder for users to understandchanges as the changed areas are not presentedindependently. aria-atomic=“true” can also be annoying, as itcan force users to listen to repetitive information that has notchanged. However, aria-atomic=“true” is necessary in caseswhere the change, when presented by itself, cannot beunderstood and contextualized by the user.

aria-controls=IDLIST

aria-controls=[IDLIST] in Table 5 is used to associate a control with theregions that it controls.

aria-describedby=IDLIST

aria-describedby=[IDLIST] in Table 6 is used to associate a region with itsdescriptions.

LIVE REGION ISSUES

Several issues have been identified with Live Regions. These include diffi-culties with: syntax consistency, determining causality, giving developers theability to group updates, handling interim updates, and providing higher-level abstractions for Web developers (Mozilla Developer Center, n.d.).

TABLE 4 aria-labelledby=[IDLIST]

Setting Description

aria-labelledby=“myLabel1myLabel2 etcEtcEtc”

aria-labelledby=[IDLIST] associates one or moreelements that serve as labels with the live region thatthey label. These elements do not have to be HTML<label> elements. If there is more than one label, thelabels are separated by a space. The labels should bepresented to the user when there is a change to theregion that they are associated with.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


TABLE 5 aria-controls=[IDLIST]

Setting Description

aria-controls=“myRegion1myRegion2 etcEtcEtc”

aria-controls=[IDLIST] associates an element with oneor more regions that it controls. If it controls morethan one region, the regions are separated by aspace. When a change to one of these regions occursbecause of a user action on the control, then thechange should be announced immediately to letusers know that their action did have an effect.

Syntax Consistency

A major change in WAI-ARIA has been altering the core markup, which cas-cades throughout the specification. The previous markup used a namespacemethod, such as aaa:live = “polite.” Recently, the markup was changed tobe more HTML friendly, such as aria-live = “polite.” The syntax change maymake ARIA adoption easier for Web designers; however, this will place anadded burden on AT vendors, who will have to update their code. Hopefully,the ARIA syntax will not go through another major change.

Determining Causality

Although WAI-ARIA has an aria-controls=[IDLIST] property to specify that acontrol will change certain live regions, if these live regions can be changedby world events, then the AT will not be able to distinguish between achange caused by the user and one that is not. This can be an importantdistinction, since changes caused by the user should be spoken immediatelyto let users know that their actions did have an effect; however, if thechange was caused by world events, then the change should be announcedaccording to the appropriate politeness setting for that region.

TABLE 6 aria-describedby=[IDLIST]

Setting Description

aria-describedby=“myDesc1myDesc2 etcEtcEtc”

aria-describedby=[IDLIST] associates one or moreelements that serve as descriptions with the liveregion that they describe. If there is more than onedescription, the descriptions are separated by a space.The descriptions should not be presented to the userwhen there is a change to the region that they areassociated with, as they are likely to be too lengthyand would annoy the user; however, there should bean easy way for users to find the description for aparticular region when they want to find out moreabout the region.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 21

Grouping Updates

Sometimes, Web developers may have an application that needs to updateseveral pieces of information at the same time. If these updates are expectedto take a noticeable amount of time, Web developers will need a way totell the AT when the updates are completed and ready to be spoken. Bygrouping these updates together, Web developers can prevent users fromhearing the same information multiple times, as well as making a largeupdate more meaningful by having all of its parts presented together. Thecurrent WAI-ARIA specification does not provide Web developers with thisability.

Interim Updates

In most cases, the AT should not announce something that is not currentlydisplayed on the page since, in general, if it is not displayed anymore, thenit is not current—skipping it will help prevent users from falling behind.However, there are cases where obsolete items should still be announced.For example, if an AJAX application provided a play-by-play description ofa game in the form of a log that only contained the last five plays, then allthe updates should be read, even if the AT were to fall behind in tryingto read all of the updates and a play disappeared from the five currentplays on the page before it could be read. It is important in this case to notskip updates that have since disappeared because they contain importantinformation that the user needs to hear in order to make sense of the mostcurrent information. There is currently no way for Web developers to specifywhether or not interim changes are relevant.

High-Level Abstractions

The WAI-ARIA specification does not have defaults for the live-region prop-erties for the roles that it has defined. Having defaults is important, as thiswould give Web developers a higher level of abstraction. Rather than try-ing to manually specify all of the live-region properties for each individualwidget, Web developers should be able to specify what type of widget theyhave and expect that there be reasonable defaults for how that widget willbehave.

CASE EXAMPLE: REEFCHAT

The main contribution of ReefChat is in demonstrating that a Web 2.0 applica-tion can be accessible to people with visual impairments. A chat application

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


FIGURE 1 A ReefChat instance.

was chosen as a Live Region use case because of the many dynamic ele-ments in the UI and fast-paced updates. The chat demonstrates how ARIALive Regions can mark up DOM mutations to be read by any AT that supportsthis markup. In addition, ReefChat messages are marked up in such a waythat they can be navigated programmatically to aid the user in accessing themost relevant information quickly. Beyond Live Regions, the chat has severalaccessibility features, including a logical navigation, the ability to pause thechat, and message prioritization.

A ReefChat instance is shown in Figure 1, with several users chatting ina chat room.

The circles in Figure 1 identify live regions. The circles around the roomtopic, chat log, and typing indicator mark the polite live regions. The squaresaround two prioritized chat messages mark assertive live regions. Also theA to C letters in Figure 1 label the difference areas in the ReefChat UI: A =Roster; B = Transcript; C = Message Compose; and D = Tips. Each sectionwill now be covered in more detail.

The roster or chatters area (A) displays users but only announces whena user is typing but not entering or leaving the chat. This is accomplished byinserting a typing indicator into the DOM with Live Region markup. Note that

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 23

<ul id=“reefchat_roster”>

<li>

<div class=“reefchat_username”>A Username</div>

</li>

<li>

<div class=“reefchat_username”>A Username</div>

//dynamically added typing node is announced on insertion

<div class=“reefchat_typing” live=“polite”>

typing…

</div>

</li>

</ul>

FIGURE 2 Roster markup.

by default each typing indicator receives by default the aria-relevant=“textadditions” and aria-atomic = “false” along with the Live Region setting. Con-sequently, AT will only announce each typing indicator individually and notthe removal of a typing indicator from the DOM. The reasoning behind thiswas that announcing when a user stopped typing is considered trivial infor-mation to a blind user, though perhaps this is an incorrect assumption anda toggle switch should be added to the ReefChat preference menu to allowa user to enable/disable what is announced, and in this case, when a userstops typing.

Of interest to developers planning to implement Live Region: Note thatin Figure 2 the roster container div does not have a Live Region setting.Only the inserted child-typing indicators receive a Live Region setting. Thetakeaway is that nesting an element within a Live Region is not required.An individual node can be arbitrarily inserted into the DOM, and an AT willpick up this mutation and announce it.

Alternately, the chat transcript area (B) uses a nested Live Region whereby default newly added messages automatically inherit their parent transcriptsettings.

The transcript markup in Figure 3 is marked up with a polite Live Regionsetting and log role, and by default all messages inherit these attributes. A role= “log” is defined so an AT will know to treat the transcript list as a log. Thearia-live = “polite” setting is used to give incoming messages a low priority

<ol id=“reefchat_transcript” role=“log” aria-live=“polite” aria-relevant=“additions”>

//Messages are appended to the transcript list here

</ol>

FIGURE 3 Chat transcript log live region.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


<li class=“reefchat_chatMessage” aria-role=“chatMessage”> <div aria-state=“timestamp” class=“timestamp”>time </div> <div aria-role=“username” class=“username”>user</div> <div class=“content”>content</div> </li>

FIGURE 4a Chat transcript normal message.

<li class=“reefchat_priorityMessage” role=“chatMessage” aria-live=“assertive”> <div aria-state=“timestamp” class=“timestamp”>time </div> <div aria-role=“username” class=“username”>user</div> <div class=“content”>content</div> </li>

FIGURE 4b Priority chat message live region.

and have them spoken/displayed as received. The aria-relevant=“additions”setting specifies that only node additions to the log are relevant and notremovals or text mutations. The aria-atomic = “false” setting informs an ATto only announce a mutation individually and not the entire transcript log.

A normal or default chat message is added to the transcript log asreceived. The Live Region markup for a normal message is displayed inFigure 4a.

Note that “chatMessage” is not an official ARIA role but is a custom roleadded to simplify the work required for an AT to assist a user navigatingthe transcript. The chat message structure also allows navigation by addingthe chatMessage role. Users accessing ReefChat through an AT like Fire Voxthat supports the chatMessage role can manually navigate through messagelogs and view all messages of importance to them. This is accomplished inFire Vox by keying ctrl + shift + left/down to go to the previous messageand ctrl + shift + right/up to go to the next message, effectively allowingqueue jumping. Using this method users can quickly find out the sequenceof high-priority messages directed to them. Chat messages are added to thechat log in sequence but are marked up differently based on priority.

Messages flagged as a priority overwrite the politeness setting with an as-sertive Live Region setting. This allows important messages to be announcedfirst. To sighted users important messages are marked up with bold via aCascading Style Sheet (CSS) property, and the message sequence is retained.The markup for a priority message that can also be visually identified by theenlarged and bolded chat text is displayed in Figure 4b.

<input type=“submit” aria-controls=“transcript” name=“Send Message” id=“reechat_sendMessage” value=“send”/>

FIGURE 5 Compose message input field.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 25

//In the HTML file

<div id=“reefchat_compose_container”>

<label for=“reefchat_compose_title”>

<h1 class=“reefchat_hidden”>Compose</h1>

</label>

…. //and so on

//In a separate CSS file included in the HTML file

.reefchat_hidden {

position: absolute;

left: -99999px;

top: -99999px;

width: 1px;

height: 1px;

overflow: hidden;

}

FIGURE 6 Offscreen HTML and CSS code.

The markup for a priority chat message is nearly identical to a defaultchat message; the only difference is the higher-priority assertive setting. Anissue encountered with this ARIA configuration is that of messages beingdiscarded. When a high volume of chat messages are being received, the ATcan quickly reach its buffer limit, and consequently low-priority messagesget dropped. in the worst case, if many assertive messages are present, high-priority messages can be dropped as well. The message prioritization will becovered in more detail in the Discussion section.

Of interest to developers planning to create a similar interface toReefChat is the markup for the Compose Message input field, which is dis-played in Figure 5.

By adding the aria-controls=“transcript” markup, the form is mapped tothe related chat log Live Region and can be identified by AT.

Beyond Live Regions, ReefChat HTML heading structure that many ATleverage for convenient navigated. By adding HTML headings, a user canaccess a menu listing of the headings by pressing a hot key from the AT.Each main area in ReefChat is marked up with a HTML H1 heading. Thisallows a user to quickly jump between the roster, transcript, compose, andtips areas.

Neither the transcript nor compose areas have a visible heading in theReefChat interface. By using CSS to display an HTML element offscreen, it ispossible to include information in the UI that only AT users will be aware ofFigure 6 contains the HTML and CSS used to accomplish this.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


The two hidden headings in ReefChat are considered trivial, and bymoving them offscreen more screen space is made available to the UI forsighted users. Conversely, the headings are useful for blind users to identifywhich area they are accessing or to allow jumping from heading to headingvia an AT.

In Figure 6, note that the CSS properties “display:none” or “display:hidden” were not used in the “.reefchat hidden” style. The use of either ofthese CSS properties will cause a screen reader to ignore any related content.Also, note the “width:1px” and “height:1px” is used instead of “width:0px;”and “height:0px.” A screen reader will ignore content with a “0px” size. Whena “1px” size is used in combination with “overflow:hidden;” any content witha size greater than “1px” will not be visually displayed. The height, width, andoverflow properties are arguably overkill but are a safe solution when contentmust not be visually displayed but be read by a screen reader. This techniqueshould only be used on content that will not receive browser focus, suchas headings, paragraphs, lists, etc. Content that can receive browser focussuch as an anchor should be avoided; otherwise this item may receive focusand disorient sighted users by taking them offscreen and far away from thepreviously visible content area.

An additional pause feature was added to ReefChat (see Figure 1) to helpblind users keep up in an active chat room. A user can activate the pausebutton and stop incoming messages from being displayed and announced.This allows users to stop the chat and catch up and read past messages attheir pace. Once users are caught up, they can activate the pause button,and the chat continues with any missed messages then being displayed andannounced.

To see ReefChat in action, visit http://reefchat.overscore.com and trythe demo.

DISCUSSION

The solution presented solves an immediate need of Web 2.0 Rich Internetapplications. Following the ARIA specification and using AJAX Live Regionsenables a graceful method of informing an AT of how a DOM update shouldbe processed. However, active environments with many updates over a shortduration of time, such as in ReefChat, pose a problem. Live Regions wereshown to be sufficient for several DOM updates at a time using differentlevels of politeness. However, what if the scale of DOM updates increasedto 20 or more at a time? If even 10 of the DOM updates were labeled as politeor assertive, the AT would be overwhelmed with information. A highly activechat environment is an excellent example. Suppose 50 participants entereda ReefChat instance. The number of DOM updates would soon overwhelm ascreen reader that supported live regions, such as Fire Vox. The user would

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 27

fall behind and be unable to participate in the chat effectively. The ARIALive Region framework cannot support the high levels of activity in a highlyactive chat environment.

ReefChat uses JavaScript logic to prioritize messages based on keywords,such as a user’s name. The implementation involved using two queues, anassertive queue and a polite queue. The assertive queue is always emptiedand announced first. Once the assertive queue is empty, the polite queue isthen announced. This queuing technique aided an AT by limiting the numberof messages to announce at once, or in the worst-case scenario, dropping theless-significant messages. This technique also aided the user by announcingthe most important messages first, and the more trivial messages second. Bydoing so, blind users can respond immediately to messages sent to themfirst and catch up with the remainder of the chat second. Additionally thepause feature helps a user catch up with new messages in an active chatenvironment.

The queuing technique could be taken further, and messages could beprioritized on more advanced criteria (Thiessen & Chen, 2008). One examplewould be searching incoming chat messages for statistical similarities to auser’s past messages. Another example would be searching for chat messagesthat are similar to the chat topic. Queuing is no doubt only a first step, andmany other more sophisticated methods have been or will be discovered.

The original implementation of ReefChat took advantage of not onlythe polite and assertive Live Region settings but also the rude setting, andchannels that were included in the previous ARIA draft. With the 1.0 re-lease of the ARIA specification, these attributes were removed. In the caseof ReefChat, having only the polite and assertive settings is very limiting,especially when message queuing. The combination of a three-tier polite-ness setting along with two channels to announce the prioritized messageswas a powerful feature. The reason given for removing the rude setting andchannels from the ARIA specification was to simplify the learning curve ofWAI-ARIA for developers new to the specification. More research is requiredbefore making a claim for or against this change in ARIA.

One problem encountered with the message-queuing technique wasthat the chat-message sequence was taken out of order. A chat may containinformation contained in the order of messages. For example, if a user isreplying to a previous message, and the reply is announced first, the intendedmeaning in the message order is lost. To help solve this problem, the abilityto enable—or more importantly, disable—message prioritization was addedto ReefChat.

Perhaps the, or one of the, most interesting findings from Reefchat isthat sighted users use the accessibility features. For example, in a SNOWonline classroom (SNOW, 2009), users often multitasked while participatingin the chat and were near but not necessarily at their keyboard. By using ascreen reader to announce new messages, and more importantly messages

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


addressed to users, they were able to participate in the chat effectively whilecompleting other tasks.

Beyond taking advantage of AT header features, and Fire Vox’s ability tokey through chat messages, additional keyboard navigation could be addedto ReefChat via roving tab index and arrow keys. A roving tab index involvesprogrammatically setting a tab index on an HTML node and giving that nodefocus. Additional behavior could be added to ReefChat via JavaScript toallow a user to use arrow keys to traverse HTML nodes. For example, whena user used a heading or tab key to enter the chat transcript area, the arrowkeys could then be used to navigate up and down the chat log and notbe dependent on an AT like Fire Vox for this functionality. Perhaps justas important, the arrow keys could be used to navigate settings dialogs. Ifonly a tab index were used to access the UI, a user would be required totab through each UI element in sequence before reaching the desired area.ReefChat has roughly 13 UI elements, though if the chat transcript alongwith chat messages is included in the tab index, the number could be inthe hundreds. For this reason, only using the tab index for top-level UIelements and arrow keys for subarea nodes should prove to be an effectivenavigation scheme in ReefChat and similar applications. The implementationof a roving tab index and using event listeners with arrow in JavaScript isbeyond the scope of this paper, but more information can be found on thehttp://wiki.codetalks.org ARIA community reference Web site.

Based on user feedback, the activity area feature previously in ReefChatwas removed because it mainly contained trivial information. To solve thisusability problem, the activity information was easily folded into the tran-script. When a user logs in or out, the transcript displays and announcesthis information. Another solution could be to simply not announce userlogin/logout at all and only leave it displayed for sighted users. Decid-ing what information was trivial and what was relevant, and in doing sohopefully creating a good user experience for blind users, was the mostchallenging aspect of developing ReefChat.

RELATED WORK

The issue of Web 2.0 accessibility has become increasingly prominent. TheWAI-ARIA specification contains current best practices and instructions onembedding accessibility states and roles into an HTML document. Prior tothis specification, there was no standard way of providing markup to makea Web 2.0 application accessible. (Prior work had been done on addingsemantics to Web content that was human readable and could be extendedto widgets with dynamic behavior, [Leventhal, 2006].)

AJAX toolkits and frameworks have also begun to mature; new projectsinclude Dojo (Dojo, n.d.) and JQuery. (JQuery, n.d.). IBM contributed to

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 29

Dojo by funding the addition of ARIA support to the library (Market Wire,2006). Dojo is the first, and currently only, JavaScript library to fully supportARIA. JQuery, an upcoming and popular JavaScript library, has begun addingsupport for ARIA.

A case example of a Web application using an AJAX toolkit such asJQuery is the Fluid project (Fluid, n.d.), which is an open-source projectdedicated to improving the user experience of other open-source projects.Fluid builds accessible, rich user-interface components that can be reusedacross Web applications and supports ARIA for all user-interface compo-nents. The project is working from a user-centered design perspective, and inparticular, the user experience of ARIA, the emerging DHTML best practices,and sharing our designs back with the wider community. Fluid is also con-tributing code to add ARIA and keyboard navigation support to the jQuerytoolkit. For more information or to get involved in the Fluid community, visithttp://fluidproject.org.

Several open-source screen readers have begun adding support forARIA, including Fire Vox (Chen, 2008), NonVisual Desktop Access (NVDA)(NVDA, n.d.), and ORCA (Orca, n.d.).

Fire Vox is an open-source, freely available talking-browser extensionfor the Firefox Web browser developed by Charles Chen. It is essentiallya screen reader that is designed for Firefox, and in addition to the basicfeatures that are expected of screen readers, such as being able to identifyheadings, links, images, etc. and providing navigational assistance, Fire Voxprovides support for MathML (W3C, 1999) and CSS speech module (W3C,2004) properties. It is also cross-platform compatible and works on Windows,Macintosh, and Linux.

Fire Vox is helping to lead the way toward AJAX accessibility by beingthe very first assistive technology to support live regions marked up withWAI-ARIA. An innovative feature of Fire Vox is the support of “interim,”which allows Web developers to specify whether or not interim changes arerelevant for a particular live region, as mentioned in the previous section. Inaddition to supporting the WAI-ARIA markup, Fire Vox also has a “smart”default mode, which will try to guess the most suitable behavior for liveregions that are not tagged with WAI-ARIA. Fire Vox also offers a strict modethat uses WAI-ARIA-tagged regions only and an off mode that completelysilences all live regions. For more information, visit the Fire Vox home pageat http://www.firevox.clcworld.net.

NVDA is a free and open-source screen reader for the Microsoft Win-dows operating system. Many other screen readers for the Windows platformcan cost up to thousands of dollars, but NVDA can provide blind users accessto Windows and its applications for no more cost than a sighted person. TheNVDA community believes wholeheartedly in accessibility standards, as thisis definitely the way to make things accessible for everyone, not just for peo-ple with one particular disability or for one particular assistive technology.

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


As NVDA takes part in the development of, and makes use of, many ac-cessibility APIs (such as MSAA, IAccessible2, and Java Access Bridge), itis able to work straight away with many different applications that followthese standards, rather than having to have custom code for each individualapplication.

Other than general application accessibility, the importance of Webaccessibility standards (e.g., ARIA) is very clear, if people with disabilitiesare to keep up with today’s dynamic and visual Web. NVDA, through its richsupport for Mozilla Firefox, and its close collaboration with Mozilla, providesaccess to ARIA-enabled Web sites, giving blind users of Windows access toWeb content that previously would not have been accessible. For moreinformation, visit the NVDA homepage at http://www.nvda-project.org.

The Gnome Project now includes a free and open-source screen readercalled Orca. The popularity of the screen reader has grown rapidly and isnow included with distributions such as Open Solaris and Ubuntu. The Orcaassistive technology helps provide access to applications and toolkits thatsupport the Assistive Technology Service Provider Interface (AT-SPI) througha combination of speech synthesis, Braille, and screen magnification. Theproject has been led by Willie Walker at the Accessibility Program Office ofSun Microsystems, Inc. and has had strong community support with manycommunity contributions. Scott Heager, through a Mozilla grant, recentlyadded Live Region support to Orca (GNOME Project, 2005b). Most ARIAwidgets are currently supported in Orca, and full ARIA support should befinalized in Orca in the coming months (GNOME Project, 2005a). For moreinformation on Orca, visit the Orca home page at http://live.gnome.org/Orca.

CONCLUSION

Accessibility for Web 2.0 Internet applications is now possible through theWAI-ARIA (W3C, 2009) specification. Using Live Regions, it was shown to bepossible to inform an AT, such as Fire Vox, of DOM updates and in doing somake ARIA-compliant Web sites and applications accessible. Highly activecontent poses a problem, however, as ReefChat demonstrated. An AT caneasily become overwhelmed with DOM update notifications, and the usercan fall behind. A solution was presented to help filter trivial informationthrough message prioritization and a pause feature to help a user keep upin an active chat environment.

ACKNOWLEDGMENTS

Our thanks to SNOW and the Mozilla Foundation for funding our project andresearch, Charles Silverman at SNOW for his design work, and Lyn Setchel

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

Live Regions 31

for his quality assurance work with ReefChat. We also thank Erin Russell andIvar Pruijin for their helpful comments and suggestions and for proofreadinga draft of this paper.

REFERENCES

AJAX Patterns. (n.d.). Drag-and-drop. Retrieved January 16, 2008, from http://AJAXpatterns.org/Drag-And-Drop

Chen, C. (2008). Fire Vox. Retrieved January 11, 2008, from http://firevox.clcworld.net

Dojo. (n.d.). Dojo, the Javascript toolkit. Retrieved September 28, 2009, from http://dojotoolkit.org

Fluid. (n.d.). Fluid—designing software that works—for everyone. Retrieved Septem-ber 28, 2009, from http://fluidproject.org

GNOME Project. (2005a). Firefox 3.0 ARIA widget support in Orca. Retrieved June 5,2009, from http://live.gnome.org/Orca/Firefox/ARIAWidgets

GNOME Project. (2005b). Firefox 3.0 Live Region support in Orca. Retrieved June 5,2009, from http://live.gnome.org/Orca/Firefox/LiveRegions

Google. (n.d.b) Google maps. Retrieved September 10, 2009, from http://maps.google.com

JQuery. (n.d.). jQuery: Write less, do more. Retrieved April 21, 2009, from http://jquery.com

Leventhal, A. (2006). Structure benefits all. Proceedings of the 2006 InternationalCross-Disciplinary Workshop on Web Accessibility (W4A): Building the mobileWeb: Rediscovering accessability? ACM International Conference ProceedingsSeries, Vol. 134, pp. 33–37. New York: ACM.

Market Wire. (2006). IBM contributes AJAX software development technology toopen source community. Retrieved June 5, 2006, from http://www.marketwire.com/press-mw/release/Ibm-681478.htmlb1?release i

Mozilla Developer Center. (n.d.). AJAX:WAI ARIA Live Regions. Retrieved Jan-uary 23, 2008, from https://developer.mozilla.org/en/docs/AJAX/:WAI ARIALive Regions

NVDA. (n.d.). Welcome to the home of NVDA. Retrieved June 5, 2008, from http://www.nvda-project.org

Orca Screen Reader. (n.d.). Orca—Gnome Live. Retrieved June 21, 2009, fromhttp://live.gnome.org/Orca

ReefChat Web Applications. (n.d.). ReefChat—An accessible Web2Ajax chat de-signed for all users. Retrieved May 1, 2008, from http://reefchat.overscore.com

SNOW (Special Needs Ontario Window), Adaptive Technology Resource Center,University of Ontario. (2009). SNOW—Cultivating Ontario’s inclusive educationcommunity. Retrieved September 28, 2009, from http://snow.utoronto.ca

Thiessen, P., & Chen, C. L. (2008). ARIA Live Regions: An introduction to channels.Journal of Access Services, 6(1&2), 215–229.

W3C Web Accessibility Initiative. (n.d.). Developing a Web accessibility busi-ness case for your organization: Overview. Retrieved June 27, 2009, fromhttp://www.w3.org/WAI/bcase

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4


World Wide Web Consortium (W3C). (1999). Mathematical Markup Language(MathML(tm)) 1.01 specification. W3C recommendation revision of 7 July 1999.Retrieved September 19, 2009, from http://www.w3.org/TR/REC-MathML

World Wide Web Consortium (W3C). (2004). CSS3 speech module W3C,working draft 16 December 2004. Retrieved September 28, 2009, fromhttp://www.w3.org/TR/css3-speech

World Wide Web Consortium (W3C). (2006). Roles for Accessible Rich Internet Ap-plications (WAI-ARIA Roles): An RDF role taxonomy with Qname support foraccessible adaptable XML applications. W3C working draft 26 December 2006.Retrieved January 17, 2008, from http://www.w3.org/TR/2006/WD-aria-role-20061220

World Wide Web Consortium (W3C). (2009). Accessible Rich Internet Applications(WAI-ARIA) 1.0. W3C Working Draft 4 February 2009. Retrieved September 28,2009, from http://www.w3.org/TR/wai-aria

Yahoo!. (n.d.a). flickr. Retrieved June 27, 2009, from http://www.flickr.com

Dow

nloa

ded

by [

Uni

vers

ity o

f C

alif

orni

a, R

iver

side

Lib

rari

es]

at 2

1:37

17

Oct

ober

201

4

live regions as a solution for web 2.0 accessibility

Documents