How to use ARIA Live Regions for dynamic content

From CodeTalks

Contents

Introduction

In the past, a Web page change could only be spoken in entirety which often annoyed a user, or by speaking very little to nothing, making some or all information inaccessible. Until recently, AT has not been able to improve this because no standardized markup existed to alert the AT to a change. Live Regions fill this gap and provide settings that can be used to notify an AT about a DOM change. Settings include where and when the update occurred and how important it is. The goal in using Live Regions is to provide the most relevant information first and limit the amount of trivial information as much as possible. Web developers should familiarize themselves with Live Regions and consider them when designing the User Interface (UI) of a Web site. Live Regions will be covered in more detail throughout this paper.


Live Region State

Live Regions fall under State in the ARIA guidelines and have many customizable settings. Below is a list of each related setting with a description.

  1. aria-live: The aria-live=POLITENESS_SETTING is used to set the priority with which AT should treat updates to live regions - the possible settings are: off/polite/assertive/rude where off is the default.
  2. aria-relevant: The aria-relevant=[LIST_OF_CHANGES] is used to set what types of changes are relevant to a live region - the possible settings are additions/removals/text/all where "additions text" is the default.
  3. aria-atomic: The aria-atomic=BOOLEAN is used to set whether or not the AT should present the live region as a whole - the possible settings are false/true where false is the default.
  4. aria-channel: The aria-channel=LEVEL is used to associate or map multiple hardware ATs to the main and notify ARIA channels - the possible settings are main/notify where main is the default.
  5. aria-controls: The aria-controls=[IDLIST] is used to associate a control with the regions that it controls. Regions are identified just like a an ID in a div, and multiple regions can be associated with a control using a space, e.g. aria-controls="myRegionID1 myRegionsID2".
  6. aria-labelledby: The aria-labelledby=[IDLIST] is used to associate a region with its labels, similar to aria-controls but instead associating labels to the region and again label identifiers are separated with a space.
  7. aria-describedby: The aria-describedby=[IDLIST] is used to associate a region with its descriptions, similar to aria-controls but instead associating descriptions to the region and description identifiers are separated with a space.

Code Examples

  • Roster
  • One Page Dynamic Web Site
  • (to do) simple portal
  • (to do) nesting live regions with many cases

Use Case: Roster

A blog site would like to display a list of users currently logged on. Display a list of users where a user's log-in and log-out status will be reflected dynamically (without a page reload).

<ul id="roster" role="region" aria-live="polite" aria-atomic="true" aria-relevant="additions removals">
	<!-- use JavaScript to add remove users here-->
</ul>

The role="region", region was chosen because neither log nor status made sense, which left the generic "region" attribute. The aria-live="polite", polite was chosen because the timeliness of user status would not be a priority. The aria-atomic="true", true was chosen so only the current status update would be spoken and not the entire roster. The aria-relevant="additions removals", additions removals" was chosen so users added to the roster, as well as users removed from the roster will be spoken. Channels were not used because the complexity of dynamic content on the site is low with only a dynamic roster.

Use Case: One Page Dynamic Web Site

A web developer gets carried away with JavaScript, and decides that his/her Web site will have one index.html page where navigated to content is displayed dynamically in a region. The Web page will have navigation bar with sections, that when activate, the related content from that section will be dynamically displayed replacing the old content (without a page refresh). Also, the developer would like a news area that displays frequently updated news links.

<div id="siteContainer">
<ol id="navigation">
	<li><a href="main">Main</a></li>
	<li><a href="about">About</a><li>
	<li><a href="links">links</a></li>
</ol>
<div id="content" role="document" aria-live="assertive" aria-atomic="true" relevant="additions">
	<!--Use JavaScript to replace content here -->

        <div id="news" aria-live="polite" aria-atomic="false">
                <!--Add/Remove news updates here -->
        </div>
</div>
</div>

The anchors in the navigation list would trigger the content div updates. The role="document", document was chosen because the content would read and treated like a document. The aria-live="polite", polite was chosen because a higher priority was not needed with this being the only dynamic content on the Web site. The assertive or rude attribute values could have been assigned to aria-live with the same results, however if additional dynamic content is added in the future, chances are that it will have a higher priority and the low priority content live region will still make sense. The aria-atomic="true", true attribute was chosen because the update should be treated as a whole with all additions read as a group and not independently. The aria-relevant="additions", additions attribute was chosen because only additions should be spoken and not the removal of past content. The news div inherits its parent's ARIA properties, and the only changes were aria-live="polite" and aria-atomic="false". The polite setting was chosen with the assumption that many updates that may not be relevant to the user would be a poor user experience. Similarly, atomic was set to false so only the current new update would be announced and not N news posts which would in most cases be annoying.