1. wai-aria
ANINTRODUCTIONTOACCESSIBLERICHINTERNETAPPLICATIONS
Patrick H. Lauke / Version 1.0.24012015

2. what is ARIA
and why do we need it?

3. the problem
it's "easy" (in most cases) to make static web content accessible, but
nowadays the web strives to be an application platform
complex web applications require structures (e.g. interactive controls)
that go beyond what regular HTML offers (though some of this
introduced with HTML5 ... more on that later)

4. jQuery UI

5. Polymer Project

6. the problem
when building interactive controls, some (too many) web developers
go "all out" on the JavaScript/CSS, but ignore/sidestep regular HTML
controls completely

7. <div onclick="...">Test</div>
faked button

8. <div tabindex="0"
onclick="...">Test</div>
faked button with focus

9. <div tabindex="0"
onkeyup="..."
onclick="...">Test</div>
faked button with focus and keyboard handling

10. for a sighted mouse/keyboard
user
this is a button...

11. ...but what about a
screenreader user?

12. compare <div> to a real
<button>
faked button versus real <button>

13. more complex examples...

14. jQuery UI - Slider
What's the experience here for assistive technology users?

15. the problem
generic/inappropriate HTML elements, with extra JavaScript/CSS on
top...but they're still recognised and exposed as <span> , <div> , etc

16. Operating systems and other platforms provide interfaces that expose
information about objects and events to assistive technologies
Java Accessibility API [JAPI], Microsoft Active Accessibility [MSAA], the Mac OS X
Accessibility Protocol [AXAPI], the Gnome Accessibility Toolkit (ATK) [ATK], and
IAccessible2 [IA2]

17. Marco Zehe: Why accessibility APIs matter

18. assistive technologies

19. assistive technologies
• NVDA (free)
• Narrator (free)
• JAWS
• ZoomText
• Dragon NaturallySpeaking
• VoiceOver (free)
• TalkBack (free)
• ...

20. Léonie Watson - Basic screen reader commands for accessibility
testing

21. inspection tools

22. inspection tools
test using assistive technologies (e.g. screenreaders), however...
assistive technologies often use heuristics to repair
incomplete/broken accessibility API information - so we want to
check what's actually exposed to the OS/platform.
of course, browsers also have bugs/incomplete support...

23. Firefox DOM Inspector

24. chrome://accessibility view of the raw accessibility tree

25. Accessibility Viewer (aViewer)

26. James Craig - Using ARIA 1.0 and the WebKit Accessibility Node
Inspector

27. Xcode Accessibility Inspector
(but for Chrome, remember to turn on accessibility mode in chrome://accessibility)

28. compare <div> to a real
<button>
faked button versus real <button>

31. if you use custom (not
standard HTML) widgets,
use ARIA to ensure correct info
is exposed

32. what is ARIA?

33. W3C - Accessible Rich Internet Applications (WAI-ARIA) 1.0

34. ARIA defines HTML attributes
to convey correct role, state,
properties and value

36. W3C - WAI-ARIA 1.0 - 5.3.1 The Roles Model

38. W3C - WAI-ARIA 1.0 - 6. Supported States and Properties

39. what information does ARIA provide?
• role: what type of widget is this? (e.g. 'slider')
• state: what is its situation? (e.g. 'disabled')
• identity: what does it represent? (e.g. 'volume control')
this information is mapped by the browser to the operating system's
accessibility API and exposed to assistive technologies.
extra benefit: AT will (may) automatically announce widget-specific
hints and prompts (e.g. JAWS "... button - to activate, press SPACE
bar")

40. <div tabindex="0"
role="button" onkeyup="..."
onclick="...">Test</div>
faked button with appropriate role

42. use ARIA to:
• make custom widgets understandable to assistive technology users
• programmatically indicate relationships between elements
• notify users of dynamic updates
• hide irrelevant visible content from assistive technology
• remediation of inaccessible content without completely recoding

43. ARIA roles and attributes: restrictions
• certain role s only make sense as part of a specific complex widget
• some aria-* attributes are global
• other aria-* attributes only make sense for particular role
• not all roles/attributes are supported/implemented consistently
everywhere

44. what ARIA doesn't do...
ARIA is not magic: it only changes how assistive technology
interprets content.
• make an element focusable
• provide keyboard events
• add properties
• change visible appearance
all of this is still your responsibility...

45. ARIA support: browsers
• Firefox 3+
• Internet Explorer 8+
• Safari 4+ (Mac)
• Chrome 17+

46. ARIA support: assistive technologies
• JAWS 8+ (Win)
• Windows Eyes 5.5+ (Win)
• ZoomText
• VoiceOver (OS X/iOS)
• NVDA (Win)
• ORCA (Linux)

47. ARIA support: libraries
• extJS
• jQuery
• Dojo
• GWT
• ...

48. "support" does not mean that
everything works, though...

49. In principle ARIA works in all markup languages...but obviously that
depends on user agent/AT support. We'll focus on ARIA and HTML
Sidenote: Using ARIA to enhance SVG accessibility

50. using WAI-ARIA in HTML

51. W3C - Using WAI-ARIA in HTML

52. the 5 rules of ARIA use

53. 1. don't use ARIA

55. 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.
“

56. 2. don't change native
semantics
unless you really have to / know what you're doing

57. don't do this:
<h1 role="button">heading button</h1>
do this instead:
<h1><span role="button">heading button</span></h1>
otherwise the heading is no longer a heading
(e.g. AT users can't navigate to it quickly)

58. don't do this:
<ul role="navigation">
<li><a href="...">...</a></li>
...
</ul>
do this instead:
<div role="navigation">
<ul>
<li><a href="...">...</a></li>
...
</ul>
</div>
otherwise the list is no longer a list
(e.g. AT won't announce "list with X items...")

59. 3. make interactive ARIA
controls keyboard accessible

60. All interactive widgets must be focusable and scripted to respond to
standard key strokes or key stroke combinations where applicable. [...]
Refer to the keyboard and structural navigation and design patterns
sections of the WAI-ARIA 1.0 Authoring Practices

61. 4. don't "neutralise" focusable
elements

62. don't use role="presentation" or aria-hidden="true" on a visible
focusable element. Otherwise, users will navigate/focus onto
"nothing".
<!-- don't do this... -->
<button role="presentation">press me</button>
<button aria-hidden="true">press me</button>
<span tabindex="0" aria-hidden="true">...</span>

63. 5. interactive elements must
have an accessible name

64. <!-- don't do this... -->
<span tabindex="0" role="button">
<span class="glyphicon glyphicon-remove-sign"></span>
</span>

65. <span tabindex="0" role="button" aria-label="Delete" >
<span class="glyphicon glyphicon-remove-sign"></span>
</span>
<span tabindex="0" role="button" title="Delete" >
<span class="glyphicon glyphicon-remove-sign"></span>
</span>
<span tabindex="0" role="button">
<span class="glyphicon glyphicon-remove-sign">
<span class="...">Delete</span>
</span>
</span>
refer to WAI-ARIA 1.0 - 5.2.7. Accessible Name Calculation

66. WAI-ARIA spec can be dry/technical - use for reference
W3C - WAI-ARIA 1.0 Authoring Practices more digestible.

67. ARIA and HTML5

68. ARIA is used when
building/denoting things that
native HTML can't do

69. HTML5 introduces new
elements, element types,
attributes that solve some of
these situations

70. example: HTML5 slider

71. HTML5 accessibility

72. Implementation status for HTML5 element/attribute accessibility
mappings

73. HTML5 now also includes WAI-ARIA ...

74. ... meaning we can validate pages with (static) ARIA validator.w3.org

75. common structures and widgets
(not an exhaustive list - enough to understand concepts)

76. using ARIA to provide
structure

77. heading

78. <p class="heading1">Heading 1</p>
...
<p class="heading2">Heading 2</p>
...
<p class="heading3">Heading 3</p>
...

79. <p class="heading1" role="heading" aria-level="1" >Heading 1</p>
...
<p class="heading2" role="heading" aria-level="2" >Heading 2</p>
...
<p class="heading3" role="heading" aria-level="3" >Heading 3</p>
...
example: headings
• add role="heading"
• if more than one hierarchical level, and can't be inferred from
structure, add explicit aria-level

80. list

81. <div>
<div>...</div>
<div>...</div>
<div>...</div>
...
</div>
generally more complex (big markup structures that boil down to
essentially "a list of things...")

82. <div role="list" >
<div role="listitem" >...</div>
<div role="listitem" >...</div>
<div role="listitem" >...</div>
...
</div>
example: list/listitem
• add role="list" and role="listitem"

83. landmarks

84. adapted from HTML5 Doctor - Designing a blog with html5

86. why define landmarks?
• users of assistive technologies can more easily find areas of your
page/app
• AT keyboard controls to navigate to/between landmarks
• overview dialogs listing all landmarks (e.g. NVDA)

88. doesn't HTML5 solve this?

89. adapted from HTML5 Doctor - Designing a blog with html5

91. using ARIA for
simple/standalone widgets

92. button

93. <span tabindex="0" class="...">Button?</span>
example: button

94. <span tabindex="0" role="button" class="...">Button!</span>
• add role="button"
• make sure it's focusable
• add handling of SPACE

95. toggle button

96. <span tabindex="0" class="...">Option</span>
<span tabindex="0" class="... pressed">Option</span>
example: [TODO] span and fixed with ARIA

97. <span tabindex="0" role="button"
aria-pressed="false" class="...">Option</span>
<span tabindex="0" role="button"
aria-pressed="true" class="... pressed">Option</span>
• add role="button"
• make sure it's focusable
• add handling of SPACE
• add aria-pressed and dynamically change its value

98. checkbox

99. <span tabindex="0" class="...">Option</span>
<span tabindex="0" class="... checked">Option</span>
example: checkbox

100. <span tabindex="0" role="checkbox"
aria-checked="false" class="...">Option</span>
<span tabindex="0" role="checkbox"
aria-checked="true" class="... checked">Option</span>
• add role="checkbox"
• make sure it's focusable
• add handling of SPACE
• add aria-checked and dynamically change its value
similar to toggle button, but announced differently by AT

101. aria-checked="true"
aria-checked="false"
aria-checked="mixed" <!-- "partially" checked -->
example: tri-state checkbox

102. radio button

103. <span tabindex="0" class="...">Yes</span>
<span tabindex="0" class="... selected">No</span>
<span tabindex="0" class="...">Maybe</span>
example: radio button

104. <span tabindex="-1" role="radio"
aria-checked="false" class="...">Yes</span>
<span tabindex="0" role="radio"
aria-checked="true" class="... selected">No</span>
<span tabindex="-1" role="radio"
aria-checked="false" class="...">Maybe</span>
• add role="radio"
• only single tab-stop (as with native radio buttons)
• add handling of SPACE and cursor keys
• add aria-checked and dynamically change its value
• should be contained inside role="radiogroup" (cfr. <fieldset> )

105. link

106. <span tabindex="0"
onclick="document.location(...)">link</span>

107. <span tabindex="0" role="link"
onclick="document.location(...)">link</span>
• add role="link"
• make sure it's focusable
• ensure correct ENTER keyboard handling

108. tooltip

109. <span tabindex="0" onmouseover="..." onfocus="...">...</span>
...
<span>this is the tooltip text</span>

110. <span tabindex="0" onmouseover="..." onfocus="..."
aria-describedby="tooltip" >...</span>
...
<span role="tooltip" id="tooltip">
this is the tooltip text</span>
example: tooltip
• add role="tooltip" (but seems to have no effect in AT)
• add aria-describedby pointing to id of tooltip

111. status bar

112. <span role="status" >
some form of status bar message...</span>
example: status bar
• add role="status" (varying support?)
• an example of a live region (more on this later)

113. alert message

114. <span role="alert" >
an alert message (no user interaction)</span>
example: alert
• add role="alert" (varying support?)
• an example of a live region (more on this later)

115. progress bar

116. <div>
<span style="width:40%"></span>
</div>

117. <div tabindex="0" role="progressbar" aria-label="..."
aria-valuemin="0" aria-valuemax="100"
aria-valuenow="40" aria-valuetext="40% complete" >
<span style="width:40%"></span>
</div>
example: progress bar
• add role="progressbar" (varying support?)
• add aria-valuemin , aria-valuemax , aria-valuenow
• optional aria-valuetext
• make it keyboard-focusable
• should have a name/label, e.g. aria-label

118. slider

119. <!-- taken from jQueryUI -->
<div ... class="ui-slider ...">
<span class="ui-slider-handle ..."
tabindex="0" style="left: 7%;"></span>
</div>
example: standard jQueryUI slider

120. <div ... class="ui-slider ..." role="slider"
aria-valuemin="0" aria-valuemax="100"
aria-valuenow="40" aria-valuetext="40%" >
<span class="ui-slider-handle ..."
tabindex="0" style="left: 40%;"></span>
</div>
• add role="slider"
• add aria-valuemin , aria-valuemax , aria-valuenow
• optional aria-valuetext
• ensure it handles cursor keys correctly
• should have a name/label, e.g. aria-label

121. Hans Hillen's Accessible jQuery-ui Components Demonstration

122. dialog

123. <div role="dialog" tabindex="0" aria-labelledby="dialog-header" >
<div id="dialog-header">My custom dialog</div>
...
</div>
example: jQueryUI dialog (enhanced)

124. Karl Groves - a11yDialog

125. using ARIA for
complex/composite widgets

126. menu

127. <div role="menu" </div>
<div role="menuitem" ...>...</div>
<div role="menuitem" ...>...</div>
<div role="menuitem" ...>...</div>
...
</div>

128. <div role="menubar" >
<div role="menuitem" ...> ...
<div role="menu" </div>
<div role="menuitem" ...>...</div>
<div role="menuitem" ...>...</div>
<div role="menuitem" ...>...</div>
...
</div>
</div>
...
</div>
example: Open Ajax Alliance - Menubar
most suitable for real "application-like" web-apps - arguably not
appropriate for general "website navigation"

129. W3C - Web Accessibility Tutorials - Web Application Menus

130. Adobe - Accessible Mega Menu

131. W3C - Web Accessibility Tutorials - Fly-out Menus

132. Heydon Pickering - Practical ARIA - Simple dropdowns

133. tabs / accordions

134. <div role="tablist" ...>
<div role="tab" aria-controls="panel1"
aria-selected="true" ...>Tab 1</div>
<div role="tab" aria-controls="panel2" ...>Tab 2</div>
<div role="tab" aria-controls="panel3" ...>Tab 2</div>
</div>
<div role="tabpanel" id="panel1" aria-hidden="false" >...</div>
<div role="tabpanel" id="panel2" aria-hidden="true" >...</div>
<div role="tabpanel" id="panel3" aria-hidden="true" >...</div>
example: Open Ajax Alliance: Tab Panel
variations on this theme: Marco Zehe - Advanced ARIA tip #1: Tabs in
web apps
not appropriate if you're just marking up a site navigation...

135. <div role="tablist" ...>
<div role="tab" aria-controls="panel1" ...>Tab 1</div>
<div role="tabpanel" id="panel1">...</div>
<div role="tab" aria-controls="panel2" ...>Tab 2</div>
<div role="tabpanel" id="panel2">...</div>
<div role="tab" aria-controls="panel3" ...>Tab 2</div>
<div role="tabpanel" id="panel3">...</div>
</div>
example: Hans Hillen - Accessible jQuery-ui Components: Accordion
sometimes better to keep it simple (series of expand/collapse
controls): whatsock - AccDC Technical Style Guide / AccDC Technical
Style Guide (GitHub)

136. listbox

137. <div role="listbox" aria-activedescendant="opt2" tabindex="0">
<div role="option" id="opt1">Option 1</div>
<div role="option" id="opt2" class="active">Option 2</div>
<div role="option" id="opt3">Option 3</div>
</div>
example: James Craig - multiselect listbox
• add role="listbox" on the container
• add role="option" on each option
• implement standard keyboard interaction (complex for multiselect)
• use aria-activedescendant to manage focus (more later)

138. combobox

139. <!-- similar to <select> -->
<input type="text" role="combobox" aria-expanded="true"
aria-autocomplete="list" aria-owns="optlist"
aria-activedescendant="opt2" >
<div role="listbox" id="optlist">
<div role="option" id="opt1">Option 1</div>
<div role="option" id="opt2" class="active">Option 2</div>
<div role="option" id="opt3">Option 3</div>
</div>
example: Open Ajax Alliance: Combobox with aria-
autocomplete=list
• combination of focusable text input and listbox (like
autocomplete/search suggestions)

140. tree

141. <!-- list with selectable items, expand/collapse, nesting -->
<div role="tree" >
<div role="treeitem" >...</div>
<div role="treeitem" >...</div>
<div role="treeitem" >...
<div role="group" >
<div role="treeitem" >...</div>
<div role="treeitem" >...</div>
</div>
</div>
...
</div>
example: Tree example (no ARIA used) / Tree example (with ARIA)
support very poor on mobile (as with many complex ARIA widgets)!

142. grid

143. <!-- interactive table/spreadsheet -->
<div role="grid" >
<div role="row" >
<div role="columnheader" >...</div>
<div role="columnheader" >...</div>
</div>
<div role="row" >
<div role="gridcell" >...</div>
<div role="gridcell" >...</div>
</div>
...
</div>
example: Open Ajax Alliance: Grid example
sometimes better to simplify: Dennis Lembree - Interactive elements
within a grid layout

144. managing focus and keyboard
interactions

145. the basics
to be usable – all interactive controls must be:
• focusable
• in the logical tab order
• visible when they receive focus
• have a clear indication of focus
• operable with the keyboard
• no focus trap
• focus does not cause a change of context

146. problem with custom controls
• <div> , <span> etc. are not standard controls with defined behaviors
• not focusable with keyboard by default

147. solution
• ideally, use native focusable HTML controls ( <a> , <button> , etc.)
• or add tabindex="0" , appropriate role , and manually handle
keyboard interactions

148. complex widgets and focus
• generally, complex widgets (group of radio buttons, menus, listboxes,
tab lists) only have a single "tab stop"
• interactions within the widget handled programmatically
• TAB / SHIFT + TAB moves to the next widget, not to sub-components

149. keyboard navigation within widgets
• either: "roving" tabindex (only one element inside widget has
tabindex="0" , all others tabindex="-1" )
• or: focus remains on widget itself, denote active child element with
aria-activedescendant (and manually scroll into view, provide
highlight via CSS)
not all complex widgets lend themselves to "roving" tabindex - e.g.
role="combobox" needs aria-activedescendant , as actual focus
must remain inside the textbox.
W3C WAI-ARIA 1.0 Authoring Practices - 3.1.3. Keyboard Navigation
within Widgets

150. <!-- roving tabindex example -->
<div role="radiogroup">
<div role="radio" aria-checked="true" tabindex="0" ...> ...
<div role="radio" aria-checked="false" tabindex="-1" ...> ...
<div role="radio" aria-checked="false" tabindex="-1" ...> ...
</div>
only one radio button inside the group has focus

151. <!-- roving tabindex example -->
<div role="radiogroup">
<div role="radio" aria-checked="false" tabindex="-1" ...> ...
<div role="radio" aria-checked="true" tabindex="0" ...> ...
<div role="radio" aria-checked="false" tabindex="-1" ...> ...
</div>
changing the selection dynamically changes tabindex , aria-
checked and sets focus() on the newly selected radio button

152. <!-- activedescendant example -->
<div role="radiogroup" tabindex="0" aria-activedescendant="rad1" >
<div role="radio" id="rad1" aria-checked="true" ...> ...
<div role="radio" id="rad2" aria-checked="false" ...> ...
<div role="radio" id="rad3" aria-checked="false" ...> ...
</div>
radiogroup itself takes focus - selected radio button only identified
via aria-activedescendant

153. <!-- activedescendant example -->
<div role="radiogroup" tabindex="0" aria-activedescendant="rad2" >
<div role="radio" id="rad1" aria-checked="false" ...> ...
<div role="radio" id="rad2" aria-checked="true" ...> ...
<div role="radio" id="rad3" aria-checked="false" ...> ...
</div>
changing the selection dynamically changes aria-
activedescendant on the radiogroup , aria-checked on the radio
button - but focus still remains only on the radiogroup

154. Medialize - ally.js

155. live regions

156. making AT aware of content changes
best way to notify users of assistive technologies of new content (a
new element added to the page, made visible, a change in text) is to
move focus() programmatically to it.
but this is not always possible, as it would interrupt the user's current
actions...
example: faked button with notification via focus()

157. ARIA live regions
• announce a change on content without moving focus to it
• aria-live : off , polite , assertive
• aria-atomic
• aria-relevant
example: faked button with notification using aria-live and aria-
atomic
some role s have implicit live region - e.g. role="alert"
unfortunately, support is...flaky

158. Karl Groves - jQuery Live Regions

159. drag & drop

160. Dev.Opera - Gez Lemon - Accessible Drag and Drop Using WAI-ARIA

161. • aria-grabbed
• aria-dropeffect
example: Open Ajax Alliance - Drag and Drop / Gez Lemon's Drag and
Drop example
support is still bad (particularly on mobile) - consider refactoring or
providing alternative instead

162. what about role="application" ?

163. document vs application mode
assistive technologies/screenreaders generally operate in two modes:
document mode and application mode (terminology varies)
• in document mode ("reading mode"), user can navigate freely through
the page/content with keyboard shortcuts provided by AT
• in application mode ("forms mode"), keystrokes are mostly passed
directly to page, which needs to handle all interactions
SSB Bart Group - How Windows Screen Readers Work on the Web

164. role="application"
forces application mode

165. the result
• all keystrokes can now be handled via JavaScript
• need to ensure any text/content is explicitly associated with
focusable elements, use live regions, etc
• any content areas should be given role="document" to re-enable
user control

167. (Google Mail doesn't use role="application" ... for illustrative purposes only)

168. you don't need role="application" ...
• for native HTML elements ( <button> , <select> etc)
• for common complex ARIA widgets (treeview, slider, dialog, etc)
in both cases, assistive technologies recognise them and
automatically switch to applicable mode / pass relevant keystrokes to
the page
tl;dr: in most situations, you won't need role="application"

169. use role="application" with
caution/sparingly
(generally not to entire page)

170. use role="document" to then
denote content areas

171. Marco Zehe - If you use the WAI-ARIA role “application”, please do so
wisely!

172. ARIA to explicitly define
relationships
beyond what HTML offers natively

173. example: form enhancement using aria-describedby (plus aria-
required and aria-invalid )

174. example: form enhancement using aria-labelledby

175. ARIA for remediation

176. if your page/app uses inappropriate markup, ARIA can be used to
patch some of the issues (if it can't be fixed properly)...
<table role="presentation" >
<tr>
<td>Layout column 1</td>
<td>Layout column 2</td>
</tr>
</table>
example: layout table remediation

177. web components, angular, etc?

178. Polymer - Paper Elements - Slider

179. Addy Osmani / Alice Boxhall - Accessible Web Components

180. W3C Editor's Draft - Custom Elements - 11.1 Custom Tag example

181. AngularJS Developer Guide - Accessibility with ngAria

182. recap...

183. get in touch
@patrick_h_lauke
github.com/patrickhlauke/aria
patrickhlauke.github.io/aria/presentation/
slideshare.net/redux
paciellogroup.com
splintered.co.uk