Best Practices

Share this: Share on Facebook Tweet this link

Live Regions


Description

The W3C's draft Accessible Rich Internet Applications (ARIA) specification refers to areas of a page that update dynamically without a refresh of the entire page as live regions. The dynamic nature of AJAX and dynamic content changes force assistive technologies to identify compartmentalized areas of the page that have changed, and to determine how and when users should be notified of changes that occur in these areas. The best practices under this media type specifically relate to use of the ARIA specification. WAI-ARIA roles, states and properties are included as part of the HTML5 draft specification and therefore can be used without a namespace. XHTML-based documents that include live region properties should be served as application/xml+xhtml and should be prefixed by the WAI-ARIA namespace aaa:live.

A number of accessibility issues surround the use of live regions. For example, when developers don't specify which portions of a page are live regions, screen readers and other assistive technologies will not know which areas of the page to monitor for updates. When more than one area of a page updates, screen readers will not be able to determine the type of update that is occurring, the priority that one area may have over another in announcing alerts to the user, and whether the entire area or a just a portion of it should be announced. For these reasons, developers should define and correctly mark live regions for all areas of a page that dynamically update.

Correct use of live regions allows multiple updates to occur on a page and will allow assistive technologies such as screen readers to convey this information to the user without interrupting the user's current focus in the content.

Developers must do the following to ensure that live regions are accessible and usable to persons with disabilities.

  1. Define a live region for an AJAX application
  2. Assign a priority to a live region indicating its level of politeness
  3. Define channels for live regions to allow notifications to placed ahead of other changes already in the queue without changing their priority.
  4. Define context for live regions to allow part or all of a live region to be conveyed to the user when only a portion of the live region changes
  5. Define controlling elements to alert users of what elements will change what regions on a page
  6. Provide indication of relevant changes for live regions to assist users of assistive technology in determining if content was added, deleted, etc.
  7. Provide explicit labels for live regions
  8. Provide long descriptions for complex live regions that will describe the purpose of the live region when the explicit label is not sufficient

Connect

Connect on Facebook Follow on Twitter @WebAccess4All

Recent Blog Posts

Digital Accessibility Maturity Model: DAMM Audit – Preparation

In my last post in the Digital Accessibility Maturity Model (DAMM) Series I introduced the DAMM Audit, used [...]

The Digital Accessibility Maturity Model: DAMM Audit – Overview

In my previous posts in the Digital Accessibility Maturity Model Series I’ve introduced the 10 core dimensions [...]

The Digital Accessibility Maturity Model: DAMM-HR Dimension #3 – Staff Evaluations

In my last post in the Digital Accessibility Maturity Model (DAMM) Series I covered the Reasonable Accommodations [...]

Accessible Images Using Angular

Angular.js is becoming a widely used framework for web development. The framework allows developers to create [...]

The Digital Accessibility Maturity Model: DAMM-HR Dimension #2 – Reasonable Accommodations

In the last post in the Digital Accessibility Maturity Model (DAMM) Series I discussed Dimension #2 of DAMM-HR [...]