Live Region Identification

Proposal

SC Text

For auto-updating or status information, all of the following are true:

• the name, role, and relationship to any controlling user interface components can be programmatically determined; and
• The information is not indicated as assertive unless it is critical and time-sensitive to the user.

This is a very rough draft meant to follow from the scope discussion below

• "Auto-updating" is borrowed from 2.2.2 (Pause, Stop, Hide) and seems to also be applicable here
• Is it okay to use name and role here given their WCAG definitions use "component"? Since the techniques are to use ARIA, does that then imply 4.1.2 is applicable? Admittedly this is confusing, but the concept is identical so we must use the same terminology.
• Comments on the second bullet are desired - too broad? to narrow? limit to only auto-updating? This also needs to be added as a Non-Interference SC.

Glossary Additions

• status information: dynamic content such as success, progress or warning notices, which result from either user action or application status changes, and which do not take focus

Level and Guideline

Level A. This should be moved to Perceivable principle and perhaps to GL 1.3, Adaptable.

David's SC proposal

Status messages are provided for changes in content

David's proposal for definition Status message

a message set by the content which can be presented by assistive technology to the user without virtual or actual focus, using methods that are supported by user agents, including assistive technologies​. It is notification that content has appeared, changed, or is hidden by a user action, and provides information on the result such as success, error, progress, or warning. It is less than X seconds when spoken at x wpm. ​It does not interrupt the speech in mid stream. The notification can be the actual changed content if it meets the rest of the definition above.​

Out of Scope

Changes of content may occur by using any of the following types of user interface components. However, notification of such changes is already provided by other success criteria and thus they need to be scoped out. The sections below discuss this further.

Menus, Accordions, Disclosures, Tabs, and Trees

All of these common components result in changes in content, but proper notification is provided so long as they meet SC 4.1.2 (Name, Role, Value). When this is true, their respective ARIA roles and states are announced to the user. For example, a tab is identified using role="tab" and its selection state is set using aria-selected, or an accordion node is identified with role="button" and its state with aria-expanded.

Command Buttons, Toggles, Radios, or Checkboxes

All of these components can result in changes in content, but it would be expected that notification is sufficient so long as their role is identified per SC 4.1.2 (Name, Role, Value) and their purpose is adequately described by their label or instructions per SC 3.3.2 (Labels or Instructions) and SC 2.4.6 (Headings and Labels).

The exception here is when the resultant change in content is a success, error, or other status message that cannot be known until after the control is activated. These types of changes are considered live regions and are in scope.

Modal and Alert Dialogs

Modal and alert dialogs represent significant changes in content as well as changes in context. Notification of these changes is provided properly when ARIA roles are used and focus is managed properly by moving to the dialog when it appears.

Tooltips

Tooltips represent changes in content in response to hover or focus on a component. Notification of these items should be provided by referring to the content using aria-describedby from the triggering component. This programmatic determination is arguably covered by Info and Relationships (SC 1.3.1) because the tooltip's relationship to what it describes should be programmatically determinable.

Target Scope

Status Updates

Status and alert roles (includes both success and error messages).

Auto-Updating Information

Marquee, log, and timer roles.

Progress Bars

Progress bars can be considered a special case of both status and auto-updating information, but it is a specific ARIA role with specific properties. When marked up properly, screen readers can treat these as they would outside the scope of the web.

Feeds

Feeds can be considered a special case of auto-updating information. The feed role is new in ARIA 1.1. When done right this type of continual content change can be completely transparent to the user. Extra announcements would likely disrupt consuming the parts of the feed already loaded, but the name and role identification is certainly useful.

Techniques

Sufficient

• ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
• Using role=”status”
• Using role=”log”
• Using role="timer"
• Using role="marquee"
• Using role="progressbar"
• Using role="feed" (future)
• Moving focus to new content

Advisory

• G199: Providing success feedback when data is submitted successfully
• Providing an option for users to set a preference on live content

Failure

• Using role=”alert” or aria-live=”assertive” on content which is not critical and time-sensitive