Rich Internet Applications (RIAs) offer new levels of user interactivity through a Web browser. By combining semantics, style and behavior it is possible to create a RIA that can rival a traditional desktop application. Unfortunately, much of the information exposed through RIAs via dynamic Document Object Model (DOM) updates is not accessible. The W3C Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) specification presents a solution for making these applications accessible through adding additional semantics to HTML. WAI-ARIA live regions are introduced as a technique to expose dynamic DOM updates to Assistive Technologies (AT). A live region use case, eBuddy Instant Messenger (IM), is presented as well as a tally queue to help aid a user in filtering trivial information announcements.

1. WAI-ARIA Live Regions:
eBuddy IM as a Case Example
Peter Thiessen (eBuddy)
Stephen Hockema (University of Toronto)

2. Goals
1. introduce live regions and their importance
2. propose a few techniques for handling
floods of updates

3. W4A 2007: Reprise
Previously at the W4A Charles Chen and I presented
“AJAX Live Regions: Chat as a case example”
• introduced:
• live regions
• limitations (causality, grouping updates, abstractions)
• channels
• demoed Fire Vox announcing updates from ReefChat

4. Importance of WAI-ARIA
Live Regions
Rich Internet Applications (RIA) hack HTML4 to
create desktop like User Interfaces (UI)
• dynamic updates not accessible
• live regions provide meaningful markup for AT
• W3C specification = standardized cross browser
and device (all the major browsers and screen readers)

5. Live Regions
<div aria-live=“polite”>
update(s) here
</div>
<div aria-live=“assertive”>
higher priority update(s) here
</div>
http://www.w3.org/TR/wai-aria
W3C WAI-ARIA 1.0 specification itself - very detailed.
http://dev.opera.com/articles/view/introduction-to-wai-aria
A most excellent WAI-ARIA 1.0 intro for newbs by: Gez Lemon
http://www.w3.org/TR/wai-aria-practices
Excellent for developers new to ARIA

6. Are Live Regions
Production Worthy?
• a few large scale RIAs use live regions
• ARIA HTML attributes are harmless -
won’t break you application
• more wide scale testing and use cases
wouldn’t hurt

7. What would make a good live
region use case?
• lots! of users
• wide variety of platforms and devices
• lots of dynamic updates and complex user
interactions

8. eBuddy IM
• 1 billion+ users around the world
• Web, Mobile, Console, ...
• Chat based = lots of updates
http://www.ebuddy.com
eBuddy Instant Messenger Website for Web and Mobile

9. eBuddy + live regions
Follow W3C recommendation of tacking ARIA attributes into
existing UI to expose dynamic updates. eBuddy IM had 3 main
dynamic regions:
1. <div id="container‐tabs" aria‐live=”polite”> …
2. <ol id="container‐contacts" aria-live=“polite”> …
3. <div class=“container-chat-area” role=“log”>…
Note: additional ARIA markup was removed for simplicity.

10. eBuddy + live regions
Tab list live region:
<div id="container‐tabs" aria‐live=”polite”> …
Contact list live region:
<ol id="container‐contacts" aria-live=“polite”> …

11. eBuddy + live regions
Chat session live region:
<div class=“container-chat-area” role=“log”>…

12. Demo
Typical Case
10 contacts and 10 messages in about 1 minute

13. Typical Case:
Live Regions Work
• effectively exposes DOM updates to AT
• effectively synchronizes with UI
(almost)
• appears very production worthy
• another use case coming soon: eBuddy IM

14. Demo
Edge Case Live Regions Usage
183 contacts and 20 I/O messages in about 2 minutes

15. Edge Case:
Live Regions Fail
• hard to focus: unrelated updates force user
to multi task
• easily overwhelmed: flood of updates
causes a user to fall behind
• miss timely updates: could result in a user
not participating

16. Visually: lots
of Updates

17. Another Visual Example

18. 1) Limit UI Visibility
Since AT rarely announce hidden content - minimize
the visibility of UI elements:
• (+) Simple solution to implement
• (+) Follow W3C recommendation
• (-) Could be very limiting in terms of UI creativity

19. 2) Use Assertive Setting
Live regions have a lower priority “polite” and
higher “assertive”:
• (+) Could bump priority updates up in the
queue (a chat message for example)
• (+) Follow W3C recommendation
• (-) Does not solve grouping issue - increases
problem

20. 3) Channels
(W4A 2007: Reprise)
Why have only one channel? More channel mappings
could improve information processing:
For example:
-map contact list updates to a Screen Reader channel
-map chat messages to a braille terminal
*Note: experimental solution

21. 4) Tally Queue (TQ)
Summary:
Capture all updates,create logical groupings, and
announce the active queue updates but only
announce the tally (sum) and label of inactive queues.
TQ Elements:
-one “invisible” polite live region where updates are
announced (HTML/CSS)
-(N) tally queue datastore and label (JavaScript)
-code to manage tally queue updates (JavaScript)
*Note: experimental solution

22. Same Example but With a
Tally Queue: Part 1

23. Same Example but With a
Tally Queue: Part 2

24. TQ Pseudo Code
Left as an exercise for the reader:
//Listen for Updates
attach an event listener to each dynamic region
on event publish the update
subscribe to event updates
on an update, determine the related tally queue to send update
//Active Tally Queue
Announce tally queue label on becoming active
for each stored update in the tally queue (FILO)
send update to live region area to be announced
//Inactive Tally Queue(s)
for all updates
Announce sum of related tally queue and label

25. TQ HTML and CSS
Left as an exercise for the reader:
//html
<div id="tally-container" aria-live="polite" aria-relevant=“text”>
<div id="tally-meta” aria-atomic=“true”>
<div id="tally-count"></div>
<div id="tally-label"></div>
</div>
<div id="tally-message"></div>
</div>
//css to hide tally queue visually but not from AT (WCAG2 technique)
#tally-container {
height:1px; width:1px; position:absolute; overflow:hidden; top: -10px;
}

26. TQ Pros and Cons
• (+) Improve focus and reduce disorientation
• (+) Solves the invisible UI updates issue
• (+) Potential for features to help user keep up (pause/
play, navigable history, and searchable history)
• (-) Goes against W3C recommendation
• (-) A massive N of updates could still flood the user
TQ in more detail soon: temporarily on overscore.com and
soon after on wiki.codetalks.org

27. Take Away
• Live regions are a key part of Web2 accessibility (all
the technology is in place)
• Live regions are probably production worthy (more
use cases on the way)
• Start thinking about handling floods of updates (two
possible techniques: Channels, Tally Queues)
Related paper from PARC on tweet verbosity: Bernstein, M.; Kairam, S.; Suh, B.;
Hong, L.; Chi, E. H. A torrent of tweets: managing information overload in online social streams.
CHI 2010 Workshop on Microblogging.; 2010 April 11; Atlanta, GA.

28. Resources from Slides
• eBuddy Instant Messenger: http://www.ebuddy.com
• W3C WAI-ARIA Live Region References:
• http://www.w3.org/TR/wai-aria
• http://www.w3.org/TR/wai-aria-primer
• http://www.w3.org/TR/wai-aria-practices
• Community ARIA Reference: http://wiki.codetalks.org
• ARIA introduction: http://dev.opera.com/articles/view/introduction-to-wai-aria
• Previous W4A Paper: Thiessen, Peter, Chen, Charles. Ajax Live Regions: Chat as a Case Example. Proceedings of
the 2007 international cross-disciplinary workshop on Web accessibility (W4A), 2007.
• (XEROX) PARC Research paper on tweet verbosity: Bernstein, M.; Kairam, S.; Suh, B.; Hong, L.; Chi, E.
H. A torrent of tweets: managing information overload in online social streams. CHI 2010 Workshop on Microblogging.;
2010 April 11; Atlanta, GA.

29. Questions?
Live Region Issue Possible Solution
Update Grouping: no method to group updates in
Add a live region tag to assign group labels.
ARIA - must use client side logic.
Prioritization: The assertive setting has few uses and Either add more meaningful prioritization or remove
is very limited for prioritization queuing. No setting to assertive as well.
alter natural order of updates.
Obsolete Items: Not announced and sometimes it is Add a toggle to enable/disable announcing obsolete
desirable to announce obsolete items removed from the items
DOM.
Hidden Updates: UI updates not visible on the Add a toggle to enable/disable announcing invisible
screen are not announced when brought into focus. updates brought to the for ground
Causality: No setting to determine if an update was a Add a toggle to enable/disable announcing distinction
user driven or client (system) driven update. between user and client updates.
Tell us what you would like eBuddy IM to be/do:
pthiessen@ebuddy.com

30. eBuddy is hiring
www.ebuddy.com/jobs.php