Almost all web sites and web applications today are heavily reliant on JavaScript to provide rich interactions for the user. But how can we make these interactions accessible for assistive technologies such as screen readers? The answer is WAI-ARIA – and in many cases, the aria-live property. The presentation will explore the use of WAI-ARIA and the aria-live property to alert screen readers to changes in the DOM. The presentation will also look at support for aria-live across various screen readers and how the property can be most effectively used today.
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>
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.
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.
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
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.
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
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
125. aria-relevant values of
“removals” or “all” should be
used sparingly. Assistive
technologies only need to be
informed of important change.
aria-relevant
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