aria-live: the good, the bad and the ugly

aria-livethe good

the badthe ugly

What’s the problem?

Generally speaking, HTML has a very limited set of interface controls and interactions.

As the demand for rich interactions has increased,

JavaScript has become our saviour!

JavaScript provides us with many things including:

dynamic interactions:such as drag and drop, resizing, hide and show, open and shut,

switch views etc.

widgets and components:such as modals, in-page tabs,

date pickers, page loaders, sliders etc.

However, many of dynamic interactions and widgets are

problematic for Assistive Technologies.

Assistive Technologies may not be aware of content that has been updated after the initial

page has loaded.

Many widgets are not accessible for keyboard-only users.

ARIA to the rescue!

WAI: Web Accessibility Initiative

ARIA: Accessible Rich Internet Applications

WAI-ARIA allows us to use HTML attributes to define the role, states and properties of specific HTML elements.

what is it?

Is it a widget (menu, slider, progress bar etc.) or an

important type of element (heading, region, table, form etc.)

role

what is the current state of the widget?

Is it checked, disabled etc.

state

what are the properties of the widget?

Does it have live regions, does it have relationships with other

elements, etc?

properties

ARIA also provides keyboard navigation methods for the web

objects and events.

keyboard navigation

An ARIA process?

Things to avoid

Don’t use ARIA unless you really need to.

“If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element

and adding an ARIA role, state or property to make it accessible, then do

so.”

Steve Faulkner:http://www.paciellogroup.com/blog/2014/10/aria-in-html-there-goes-the-

neighborhood/

http://www.paciellogroup.com/blog/2014/10/aria-in-html-there-goes-the-neighborhood/

Where possible, use correct semantic HTML elements.

Don’t use ARIA as a quick-fix.

<!-‐-‐ avoid this if possible -‐-‐> <span role="button">...</span>

<!-‐-‐ this is preferred -‐-‐> <button type="button">...</button>

If you must use aria

1. Alert users to the widget or elements role (button, checkbox

etc).

2. Alert users to the properties and relationships of the

element (disabled, required, other labels etc).

3. Alert users to the original state of the element (checked,

unchecked etc).

4. Alert users to changes in state of the element (now

checked etc)

5. Make sure widgets are keyboard accessible (including

predictable focus).

What is aria-live?

Let’s look at a simple scenario…

In a web application, you want a simple notification to appear at

the top of the page when a user completes a task.

Well done! Your changes have been saved

This dynamically inserted notification can cause two

problems for screen readers.

Screen readers “buffer” pages as they are loaded. Any content that is added after this time many not

be picked up by the screen reader.

problem 1:

Screen readers can only focus on one part of the page at a time. If something changes on another

area of the page, screen readers may not pick this up.

problem 2:

The aria-live attribute allows us to notify screen readers when content is updated in specific

areas of a page.

How is aria-live applied?

We can apply the aria-live attribute to any HTML element.

<div aria-‐live="polite">

</div>

If we then use JavaScript toinject/hide/show content within this element screen readers will be made aware of any DOM

changes within that element.


<!-‐-‐ Dynamic content -‐-‐> </div>

There are three possible values for aria-live:

off

<div aria-‐live="off">

</div>

Assistive technologies should not announce updates unless

the assistive technology is currently focused on that region.

aria-live=“off”

Can be used for information that is not critical for users to know

about immediately.

aria-live=“off”

polite


</div>

Assistive technologies should announce updates at the next graceful opportunity (eg end of

current sentence).

aria-live=“polite”

Can be used for warning notifications that users may

need to know.

aria-live=“polite”

assertive

<div aria-‐live="assertive">

</div>

Assistive technologies should announce updates

immediately.

aria-live=“assertive”

Should only be used if the interruption is imperative for users to know immediately

such as error alerts.

aria-live=“assertive”

Where can we use

aria-live?

The aria-live attribute can be used for any page regions that are likely to get updates after

the initial page is loaded.

Success alerts! Your changes are saved

Info alerts! Some info to be aware of

Warning alerts! Something has changed

Error alerts! Fix the error and try again

Alert messages

Dynamic stock info

Dynamic RSS feeds

Date pickers

Sortable tables

Avoid misuse

The aria-live attribute should not be used for dynamic content

that is non-critical, or just adds additional “noise” for assistive

technologies

Testing aria-live

Working on a recent project with James (Brothercake) Edwards, we needed to test how aria-live

performed across different screen readers.

We built different pages for “off”, “polite” and “assertive”. Each page had a message that would

automatically be triggered 10 seconds after page load.

This automatic trigger was important as we wanted to

observe screen reader behaviour when in the middle of

announcing content on a different area of the page.

three tests

Is the newly inserted message announced immediately when

triggered - while screen reader is silent?

Test 1:

Is the newly inserted message announced immediately when

triggered - while screen reader is currently announcing other

content?

Test 2:

Is the newly inserted message announced when navigated to?

Test 3:

browsers / screen readers

IE 11NVDA 2014.4 and JAWS 16

Chrome 39NVDA 2014.4 and JAWS 16

Firefox 34NVDA 2014.4 and JAWS 16

Windows

Chrome 39VoiceOver

Firefox 34VoiceOver

Safari 7VoiceOver

OSX

Results

“off” results

Newly inserted message should not be announced when screen

reader is silent.

“off” page - test 1

BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 1 results

Newly inserted message should not be announced when screen reader is currently announcing

other content.


BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 2 results

Newly inserted message should be announced when navigated

to by screen reader.


BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 3 results

Chrome/NVDA

did not announce the message when navigated to.

issues

“polite” results

Newly inserted message should be announced when the screen

reader is silent.

“polite” page - test 1

BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 1 results

Chrome/NVDAChrome/JAWS

Firefox/Voiceover

did not announce the message when the screen reader was

silent.

issues

Newly inserted message should not be announced when screen reader is currently announcing other content, but should be

announced at the next available pause.


BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 2 results


Firefox/Voiceover

did not announce the message at the next available pause.

issues




BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 3 results

Chrome/JAWS


issues

“assertive” results

Newly inserted message should be announced when screen

reader is silent.

“assertive” page - test 1

BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 1 results


Firefox/Voiceover

did not announce the message when the screen reader was

silent.

issues

Newly inserted message should be announced when screen

reader is currently announcing other content.


BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 2 results

IE11/NVDAIE11/JAWS

Firefox/NVDAFirefox/JAWS

did not announce the message immediately as the message was

triggered. They all waited until there was a pause.

issue 1


Firefox/Voiceover

did not announce the message immediately as the message was

triggered or after a pause.

issue 2




BROWSER

IE 11 (Win)

Chrome 39 (Win)

Firefox 34 (Win)

Chrome 39 (OSX)

Firefox 34 (OSX)

Safari 7 (OSX)

NVDA JAWS VOICE

test 3 results

Chrome/JAWS


issues

Take-aways

Rather depressingly, aria-live has some support issues.

Currently, “polite” is slightly better supported than “assertive” so it is

the preferred option.


</div>

Other attributes

There are also a range of other attributes that can be used associated with live regions,

(though their support is sometimes patchy).

aria-atomic

<!-‐-‐ true attribute -‐-‐> <div aria-‐live="off" aria-‐atomic="true"> </div>

<!-‐-‐ false attribute -‐-‐> <div aria-‐live="off" aria-‐atomic="false"> </div>

Indicates whether assistive technologies will present all, or

only parts of, the changed region based on the change

notifications defined by the aria-relevant attribute.

aria-atomic

true: Present the region as a whole when changes are

detected.

false: Present only the changed regions. (default)

aria-atomic

aria-relevant

<!-‐-‐ all attribute -‐-‐> <div aria-‐live="off" aria-‐relevant="all"> </div>

<!-‐-‐ additions attribute -‐-‐> <div aria-‐live="off" aria-‐relevant="additions"> </div>

<!-‐-‐ removals attribute -‐-‐> <div aria-‐live="off" aria-‐relevant="removals"> </div>

<!-‐-‐ text attribute -‐-‐> <div aria-‐live="off" aria-‐relevant="text"> </div>

<!-‐-‐ all attribute -‐-‐> <div aria-‐live="off" aria-‐relevant="all"> </div>

<!-‐-‐ multiple attributes -‐-‐> <div aria-‐live="off" aria-‐relevant="text, removals"> </div>

Describe semantically meaningful changes, as

opposed to merely presentational ones.

aria-relevant

aria-relevant values of “removals” or “all” should be

used sparingly. Assistive technologies only need to be informed of important change.

aria-relevant

aria-busy

<!-‐-‐ true attribute -‐-‐> <div aria-‐live="off" aria-‐busy="true"> </div>

<!-‐-‐ false attribute -‐-‐> <div aria-‐live="off" aria-‐busy="false"> </div>

Indicates whether an element, and its subtree, are currently

being updated.

aria-busy

If multiple parts of the same element need to be loaded or

modified, they can set aria-busy to “true” during initial load, and

then “false” when the last part is loaded.

aria-busy

role=alert

<div role="alert"> </div>

Used to define a message with important, and usually time-

sensitive, information.

role=alert

The alert role goes on the node containing the alert message.

role=alert

Elements with the role=“alert” have an implicit aria-live value of “assertive”, and an implicit

aria-atomic value of “true”.

role=alert

role=alertdialog

<div role="alertdialog"> </div>

A type of dialog that contains an alert message, where initial focus goes to an element within

the dialog.

role=alertdialog

The “alertdialog” role goes on the node containing both the alert message and the rest of the

dialog.

role=alertdialog

Unlike alert, “alertdialog” can receive a response from the user - such as a “Confirm” or

“Save” button.

role=alertdialog

Conclusion

The aria-live attribute is a very powerful and effective method

of keeping screen readers informed about changes the

page.

As with any aria- attributes, you should test heavy before using

and use with care!

http://maxdesign.com.au/jobs/sample-accessibility/10-notifications/index.html

Our test results:

http://maxdesign.com.au/jobs/sample-accessibility/10-notifications/index.html

@brothercake

@russmaxdesign

Date post:	14-Aug-2015
Category:	Software
Upload:	russ-weakley
View:	3,756 times
Download:	0 times

aria-live: the good, the bad and the ugly

Software