An introduction to basic ARIA principles, for use in accessible web applications, especially with dynamic JavaScript. Topics include when to use ARIA, what it can accomplish, keyboard interaction patterns, AJAX, tabpanel widget, the accessibility inspector, and how ARIA emulates native applications, using the accessibility API.
2. The First Rule of Using ARIA:
NEVER use ARIA
unless you have to.
(Use native HTML controls and elements whenever possible.)
3. The 2nd Rule of Using ARIA:
ALWAYS use ARIA
when you have to.
(Some things can’t be done any other way, especially with dynamic content.)
4. The Third Rule of Using ARIA:
Go All In.
Learn How to use ARIA right.
(Using ARIA incorrectly can actually be worse than not using it at all.)
5. Going all in...
Halfway solutions or hybrids
make adoption harder.
(Like the unsuccessful
attempt in the late 1970s in
the U.S. to gradually convert
us to the metric system)
6. The Fourth Rule of Using
ARIA:
Test the results
with real screen readers.
(It’s the only way to know if your code actually does what it’s supposed to.)
8. ARIA does NOT benefit:
People who are deaf
People who are color-blind
Sighted keyboard users
People with Low vision
(unless they use a screen reader)
People with cognitive disabilities
(unless they use a screen reader)
9. ARIA DOES benefit:
People who use screen readers
(And to a lesser extent people who use voice
recognition)
10. Web Applications
and Dynamic Content
ARIA is designed to make web applications
behave more like native applications
It takes advantage of the accessibility API in
operating systems and browsers
11. The Accessibility Inspector
In Mac OSX
XCode > Open Developer Tool > Accessibility
Inspector
Hover mouse cursor over the object to have it
list the accessibility properties
13. How a Developer Can Make a
Screen Reader Say Something
Load a new page (e.g. links, form submission… or
reload the same page)
Move the keyboard focus to the new content
Use an ARIA live region to make an
announcement (usually without moving focus)
Add or alter ARIA attributes
14. Live Announcements
For when you need to say something to the user
NOW!
(or as soon as the screen reader is finished
with what it’s already saying;
“polite” or “assertive” modes)
15. Live Regions
It is an empty container, waiting for content to be
injected by JavaScript:
Before:
<div aria-live=”polite”></div>
After:
<div aria-live=”polite”>Hello!</div>
16. Live Regions
The container should be on the page
on page load
The container must be empty to begin with
(don’t pre-load the live region with content)
17. Roles, Names, Values
ARIA communicates information about elements
and widgets, including dynamic changes to those
elements and widgets
22. Content Type Roles
document (normal “browse mode”)
application (widgets; use only when the
widget needs to control keyboard event
handlers)
presentation (overrides the native semantic
meaning of an element; essentially turns it
into a generic <div> or <span>)
26. Value (States)
What can this object do?
What is its status right now?
Examples:
aria-selected=”true”
aria-expanded=”false”
aria-checked=”true”
27. Value (Relationships)
How is this widget related to other widgets?
Examples:
aria-controls=”panel1”
aria-owns=”widget2”
aria-flowto=”div1” (not well supported yet)
29. Navigation of ARIA Widgets
Tab to the ARIA widget
Tab past it (not within it)… OR…
Use arrow keys to navigate within it
Note that this is the general model, for things like tab lists, tree views, application
menus, etc. Not everything you can do with ARIA would be considered a widget,
so there are exceptions to the above keyboard pattern.
30. Keyboard Focus Management
Keyboard activates a button
Content appears
The keyboard focus goes to the new content
The user submits data or dismisses the content
The focus goes back to the original button
(or to an alternate logical location)
34. AJAX
The worst sound a person can hear after
activating a button is… silence
Always ensure the screen reader updates the user
when important updates happen
35. AJAX: Virtual Buffer Issues
You MUST insert an intentional pause AFTER the
AJAX content loads
The pause is necessary to allow the screen reader
to populate its virtual buffer
A typical pause can be about 1 second
(Use native HTML controls and elements whenever possible.)
(Some things can’t be done any other way, especially with dynamic content.)
When developers first learn about ARIA, they often start applying ARIA attributes everywhere, thinking they’re adding accessibility features, but if you don’t know what you’re doing with ARIA, you can actually make things LESS accessible.
The graphic shows a speed limit sign showing 15 miles per hour
(It’s the only way to know if your code actually does what it’s supposed to.)
The accessibility inspector in Mac OSX showing a tabpanel widget in a native application on the left, and a tabpanel widget in a web application on the right. Both of them show “AXTabGroup” as the parent, with “AXRadioButton” as the child. In other words, the web page is essentially acting like native code, and will be treated by the screen reader as a native component.
Note: You can’t use these in your code. These are just categories of roles. I included them here for the sake of completeness.
Note that this is the general model, for things like tab lists, tree views, application menus, etc. Not everything you can do with ARIA would be considered a widget, so there are exceptions to the above keyboard pattern.
For example, the source code regions on this page:
https://dequeuniversity.com/library/aria/tabpanels-accordions/tabpanel