Download - aria-live: the good, the bad and the ugly
dynamic interactions:such as drag and drop, resizing, hide and show, open and shut,
switch views etc.
Assistive Technologies may not be aware of content that has been updated after the initial
page has loaded.
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 are the properties of the widget?
Does it have live regions, does it have relationships with other
elements, etc?
properties
“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/
<!-‐-‐ avoid this if possible -‐-‐> <span role="button">...</span>
<!-‐-‐ this is preferred -‐-‐> <button type="button">...</button>
2. Alert users to the properties and relationships of the
element (disabled, required, other labels etc).
In a web application, you want a simple notification to appear at
the top of the page when a user completes a task.
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.
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.
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”
Assistive technologies should announce updates at the next graceful opportunity (eg end of
current sentence).
aria-live=“polite”
Should only be used if the interruption is imperative for users to know immediately
such as error alerts.
aria-live=“assertive”
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
The aria-live attribute should not be used for dynamic content
that is non-critical, or just adds additional “noise” for assistive
technologies
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.
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:
IE 11NVDA 2014.4 and JAWS 16
Chrome 39NVDA 2014.4 and JAWS 16
Firefox 34NVDA 2014.4 and JAWS 16
Windows
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.
“off” page - test 2
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
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
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.
“polite” page - test 2
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
Chrome/NVDAChrome/JAWS
Firefox/Voiceover
did not announce the message at the next available pause.
issues
Newly inserted message should be announced when navigated
to by screen reader.
“polite” page - test 3
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
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 be announced when screen
reader is currently announcing other content.
“assertive” page - test 2
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
Chrome/NVDAChrome/JAWS
Firefox/Voiceover
did not announce the message immediately as the message was
triggered or after a pause.
issue 2
Newly inserted message should be announced when navigated
to by screen reader.
“assertive” page - test 3
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
There are also a range of other attributes that can be used associated with live regions,
(though their support is sometimes patchy).
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
<!-‐-‐ multiple attributes -‐-‐> <div aria-‐live="off" aria-‐relevant="text, removals"> </div>
aria-relevant values of “removals” or “all” should be
used sparingly. Assistive technologies only need to be informed of important change.
aria-relevant
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
Elements with the role=“alert” have an implicit aria-live value of “assertive”, and an implicit
aria-atomic value of “true”.
role=alert
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
The aria-live attribute is a very powerful and effective method
of keeping screen readers informed about changes the
page.
http://maxdesign.com.au/jobs/sample-accessibility/10-notifications/index.html
Our test results: