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

aria-live
the good
the bad
the ugly

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.

WAI: Web Accessibility Initiative
ARIA: Accessible Rich Internet
Applications

WAI-ARIA allows us to use HTML
attributes to deﬁne the role,
states and properties of
speciﬁc 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

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/

Where possible, use correct
semantic HTML elements.
Don’t use ARIA as a quick-ﬁx.

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

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).

Let’s look at a simple
scenario…

In a web application, you want a
simple notiﬁcation to appear at
the top of the page when a user
completes a task.

Well done! Your changes have been saved

This dynamically inserted
notiﬁcation 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 speciﬁc
areas of a page.

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

If we then use JavaScript to
inject/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:

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”

</div>

announce updates at the next
graceful opportunity (eg end of
current sentence).
aria-live=“polite”

Can be used for warning
notiﬁcations that users may
need to know.
aria-live=“polite”

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”

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:

announced immediately when
triggered - while screen reader
is currently announcing other
content?
Test 2:

announced when navigated to?
Test 3:

IE 11
NVDA 2014.4 and JAWS 16
Chrome 39
Firefox 34
Windows

Chrome 39
VoiceOver
Firefox 34
VoiceOver
Safari 7
VoiceOver
OSX

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

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

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

be announced when the screen
reader is silent.
“polite” page - test 1

Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
when the screen reader was
silent.
issues

other content, but should be
announced at the next available
pause.

Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
at the next available pause.
issues

Chrome/JAWS
when navigated to.
issues

be announced when screen
reader is silent.
“assertive” page - test 1

be announced when screen
other content.

IE11/NVDA
IE11/JAWS
Firefox/NVDA
Firefox/JAWS
immediately as the message was
triggered. They all waited until
there was a pause.
issue 1

Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
immediately as the message was
triggered or after a pause.
issue 2

Rather depressingly, aria-live has
some support issues.

Currently, “polite” is slightly better
supported than “assertive” so it is
the preferred option.

There are also a range of other
attributes that can be used
associated with live regions,
(though their support is
sometimes patchy).

<!-‐-‐ 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
notiﬁcations deﬁned 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

<!-‐-‐ 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>

<!-‐-‐ 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

<!-‐-‐ 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
modiﬁed, they can set aria-busy
to “true” during initial load, and
then “false” when the last part is
loaded.
aria-busy

Used to deﬁne 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

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 “Conﬁrm” 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.

As with any aria- attributes, you
should test heavy before using
and use with care!

http://maxdesign.com.au/jobs/
sample-accessibility/10-
notiﬁcations/index.html
Our test results:

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

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

Semelhante a aria-live: the good, the bad and the ugly (20)

Mais de Russ Weakley

Mais de Russ Weakley (20)

Último

Último (20)

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