1.
aria-live
the good
the bad
the ugly

2.
What’s the
problem?

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

4.
As the demand for rich
interactions has increased,
JavaScript has become our
saviour!

5.
JavaScript provides us with
many things including:

6.
dynamic interactions:
such as drag and drop, resizing,
hide and show, open and shut,
switch views etc.

7.
widgets and components:
such as modals, in-page tabs,
date pickers, page loaders,
sliders etc.

8.
However, many of dynamic
interactions and widgets are
problematic for Assistive
Technologies.

9.
Assistive Technologies may not
be aware of content that has
been updated after the initial
page has loaded.

10.
Many widgets are not accessible
for keyboard-only users.

11.
ARIA to the
rescue!

12.
WAI: Web Accessibility Initiative
ARIA: Accessible Rich Internet
Applications

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

14.
what is it?
Is it a widget (menu, slider,
progress bar etc.) or an
important type of element
(heading, region, table, form etc.)
role

15.
what is the current
state of the widget?
Is it checked, disabled etc.
state

16.
what are the
properties of the widget?
Does it have live regions, does
it have relationships with other
elements, etc?
properties

17.
ARIA also provides keyboard
navigation methods for the web
objects and events.
keyboard navigation

18.
An ARIA
process?

19.
Things to avoid

20.
Don’t use ARIA unless you
really need to.

21.
“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/

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

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

24.
If you must
use aria

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

26.
2. Alert users to the properties
and relationships of the
element (disabled, required,
other labels etc).

27.
3. Alert users to the original
state of the element (checked,
unchecked etc).

28.
4. Alert users to changes in
state of the element (now
checked etc)

29.
5. Make sure widgets are
keyboard accessible (including
predictable focus).

30.
What is
aria-live?

31.
Let’s look at a simple
scenario…

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

33.
Well done! Your changes have been saved

34.
This dynamically inserted
notification can cause two
problems for screen readers.

35.
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:

36.
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:

37.
The aria-live attribute allows us
to notify screen readers when
content is updated in specific
areas of a page.

38.
How is
aria-live applied?

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

40.
<div aria-­‐live="polite">
</div>

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

42.
<div aria-­‐live="polite">
<!-­‐-­‐ Dynamic content -­‐-­‐>
</div>

43.
There are three possible values
for aria-live:

44.
off

45.
<div aria-­‐live="off">
</div>

46.
Assistive technologies should
not announce updates unless
the assistive technology is
currently focused on that region.
aria-live=“off”

47.
Can be used for information that
is not critical for users to know
about immediately.
aria-live=“off”

48.
polite

49.
<div aria-­‐live="polite">
</div>

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

51.
Can be used for warning
notifications that users may
need to know.
aria-live=“polite”

52.
assertive

53.
<div aria-­‐live="assertive">
</div>

54.
Assistive technologies should
announce updates
immediately.
aria-live=“assertive”

55.
Should only be used if the
interruption is imperative for
users to know immediately
such as error alerts.
aria-live=“assertive”

56.
Where can
we use
aria-live?

57.
The aria-live attribute can be
used for any page regions that
are likely to get updates after
the initial page is loaded.

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

59.
Dynamic stock info

60.
Dynamic RSS feeds

61.
Date pickers

62.
Sortable tables

63.
Avoid misuse

64.
The aria-live attribute should not
be used for dynamic content
that is non-critical, or just adds
additional “noise” for assistive
technologies

65.
Testing
aria-live

66.
Working on a recent project with
James (Brothercake) Edwards,
we needed to test how aria-live
performed across different
screen readers.

67.
We built different pages for “off”,
“polite” and “assertive”. Each
page had a message that would
automatically be triggered 10
seconds after page load.

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

69.
three tests

70.
Is the newly inserted message
announced immediately when
triggered - while screen reader
is silent?
Test 1:

71.
Is the newly inserted message
announced immediately when
triggered - while screen reader
is currently announcing other
content?
Test 2:

72.
Is the newly inserted message
announced when navigated to?
Test 3:

73.
browsers /
screen readers

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

75.
Chrome 39
VoiceOver
Firefox 34
VoiceOver
Safari 7
VoiceOver
OSX

76.
Results

77.
“off” results

78.
Newly inserted message should
not be announced when screen
reader is silent.
“off” page - test 1

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

80.
Newly inserted message should
not be announced when screen
reader is currently announcing
other content.
“off” page - test 2

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

82.
Newly inserted message should
be announced when navigated
to by screen reader.
“off” page - test 3

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

84.
Chrome/NVDA
did not announce the message
when navigated to.
issues

85.
“polite” results

86.
Newly inserted message should
be announced when the screen
reader is silent.
“polite” page - test 1

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

88.
Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
did not announce the message
when the screen reader was
silent.
issues

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

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

91.
Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
did not announce the message
at the next available pause.
issues

92.
Newly inserted message should
be announced when navigated
to by screen reader.
“polite” page - test 3

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

94.
Chrome/JAWS
did not announce the message
when navigated to.
issues

95.
“assertive” results

96.
Newly inserted message should
be announced when screen
reader is silent.
“assertive” page - test 1

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

98.
Chrome/NVDA
Chrome/JAWS
Firefox/Voiceover
did not announce the message
when the screen reader was
silent.
issues

99.
Newly inserted message should
be announced when screen
reader is currently announcing
other content.
“assertive” page - test 2

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

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

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

103.
Newly inserted message should
be announced when navigated
to by screen reader.
“assertive” page - test 3

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

105.
Chrome/JAWS
did not announce the message
when navigated to.
issues

106.
Take-aways

107.
Rather depressingly, aria-live has
some support issues.

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

109.
<div aria-­‐live="polite">
</div>

110.
Other
attributes

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

112.
aria-atomic

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

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

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

116.
true: Present the region as a
whole when changes are
detected.
false: Present only the changed
regions. (default)
aria-atomic

117.
aria-relevant

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

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

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

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

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

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

124.
Describe semantically
meaningful changes, as
opposed to merely presentational
ones.
aria-relevant

125.
aria-relevant values of
“removals” or “all” should be
used sparingly. Assistive
technologies only need to be
informed of important change.
aria-relevant

126.
aria-busy

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

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

129.
Indicates whether an element,
and its subtree, are currently
being updated.
aria-busy

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

131.
role=alert

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

133.
Used to define a message with
important, and usually time-
sensitive, information.
role=alert

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

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

136.
role=alertdialog

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

138.
A type of dialog that contains
an alert message, where initial
focus goes to an element within
the dialog.
role=alertdialog

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

140.
Unlike alert, “alertdialog” can
receive a response from the
user - such as a “Confirm” or
“Save” button.
role=alertdialog

141.
Conclusion

142.
The aria-live attribute is a very
powerful and effective method
of keeping screen readers
informed about changes the
page.

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

144.
http://maxdesign.com.au/jobs/
sample-accessibility/10-
notifications/index.html
Our test results:

145.
@brothercake
@russmaxdesign