1. The ARIA Technology
Stack: Browsers and
Screen Readers
Jonathan Avila
Bryan Garaventa

2. About SSB BART Group
• Unmatched Experience
• Accessibility Focus
• Implementation-Oriented
Solutions
• Solutions That Reduce Legal
Risk
• Organizational Stability and
Continuity
• Knowledge That Is Up-to-Date,
All the Time
• Published and Peer Review
Auditing Methodology
• Fourteen hundred organizations
(1445)
• Fifteen hundred individual
accessibility best practices (1595)
• Twenty-two core technology
platforms (22)
• Fifty-five thousand audits (55,930)
• One hundred fifty million
accessibility violations
(152,351,725)
• Three hundred sixty-six thousand
human validated accessibility
violations (366,096)

3. Agenda
• About SSB BART Group
• ARIA
• DOM and Accessibility APIs
• Screen Reader View
• ARIA Examples and Best
Practices
• References
3

4. ARIA
Overview
• Accessible Rich Internet Applications Specification (ARIA)
– Proposed recommendation of the W3C
• ARIA is a set of attributes added to markup such as HTML
– <div id="s1" role="progressbar" aria-valuenow="50" aria-
valuemin="0" aria-valuemax="100" aria-valuetext="100
percent" />
– HTML5 doctype supports ARIA as valid
• Use native semantics whenever possible
– Use progressive enhancement
• Does not change appearance of the web page
• Focuses on access by screen readers
– Will change screen reader behavior for better or worse
4

5. ARIA
• Provide support to users of assistive technology in three
main areas that were not previously addressed by (X)HTML:
– Indication of main structural areas of a page
– Creation of roles and properties of rich user interface elements
• e.g. custom controls such as ones that use JavaScript, AJAX,
etc.
– Method to indicate alerts, page changes, and dynamically
updating information
• Support by browsers and AT is not consistent
Overview (cont.)
5

6. ARIA
Common Assistive Technology with Support for ARIA
Screen reader Support
• JAWS for Windows 10+ (most common screen reader)
– Best support in IE
• Non-visual Display Access 2012+ (NVDA) – open source
– Best support in Firefox
• Window-Eyes 8.0+
• VoiceOver (Mac OS 10.5+ and iOS 4+)
Other AT support
• Speech recognition – little or no support
• Screen magnification – some limited support
6

7. ARIA
Browser Support of ARIA
Browsers
• Internet Explorer 8+ (Windows)
• Firefox 3+ (Windows, Linux, Mac, Android)
• Chrome (Windows, Mac, Android)
• Safari 4+ (Mac OS and iOS)
ARIA roles and properties are translated into platform level
accessibility APIs by the browser
7

8. ARIA
• Supported by many JavaScript frameworks
– JQuery UI
– Dojo/Dijit
– GWT
– Yahoo UI
– Others
• Support levels are different and have limitations
– AccDC – Accessibility API
Framework Support
8

9. DOM and Accessibility APis
Two ways AT obtains information and give commands
• Document Object Model (DOM)
• Applications programming interface (API)
Note: Both ways are used simultaneously as neither may be
complete enough
Overview
9

10. DOM and Accessibility APIs
DOM
• HTML structure tree with nodes representing elements and
text
• Attributes (properties of objects)
• Events (actions, e.g. click, keypress, onload, etc.)
• Associated styles (CSS) for rendering content
10

11. DOM and Accessibility APIs
Accessibility APIs
• Applications Programming Interface (API)
– Interface for programs to communicate with others
• Accessible browsers implement one ore more accessibility
API (AAPI) that is built into the browser
– May be tied into the operating system or platform
• Accessibility API
– Translates DOM and ARIA properties and events into
API properties and events
– Exposes public Properties, Methods, and Events
• These can be queried or set by screen readers, to
retrieve information
11

12. DOM and Accessibility APIs
Browser AT Interaction Process
AT ViewBrowser
View
DOM APIs
Assistive
Technology
Use
r
Browser
Controls
12

13. DOM and Accessibility APIs
Browser Support of APIs
• There are different accessibility APIs
• Browsers render ARIA roles and
properties to platform level AAPIs
including platform level events
– MSAA (Firefox and IE)
– UI Automation (IE, some FF)
– iAccessible2 (Firefox)
– ATK/AT-SPI (Linux)
• AT requires different techniques for
accessing the browser’s API and DOM
• Not consistent across browsers
13

14. Screen Reader View
Overview
• Generates a virtual representation (document) of the page
elements
• Place links, buttons, form fields, etc. on a line by themselves
• Appends or prepends the role in the text of the document
• Contains a "forms/focus" mode and a "virtual/browse" view
mode
– Allows dual use of keystrokes such as arrows and letter
to navigate virtual documents
– Allows support for interactive controls such as input fields
• May automatically go into this interactivity mode
14

15. Screen Reader View
Example
Visited link Need Help?
Register: Complete all fields in
the form.
Name
Name Edit
E-mail
Email Edit
Register Button
15

16. Screen Reader View
Dynamic Content
• Virtual view is copy
(cache) of page
– screen readers have
become very good
about watching for
DOM changes to
update view
– users shouldn’t end up
with stale page
content when ARIA
and proper DOM
techniques are used
Virtual
view
DOM
Changes
User
Actions
Page
Refresh
ARIA
Changes
16

17. Screen Reader View
Keystroke Interaction
What happens when a key is pressed
Key Enter/Spacebar Arrows Letters Multi-key
keystroke
Virtual
View
Call click event Move to
next unit in
Virtual view
Perform
quick
navigation,
command, or
nothing
Sent to
page
Forms
Mode
Sent to page Sent to
page
Sent to page Sent to
page
17

18. ARIA Examples and Best Practices
Code Example
• API name, role, state, or value are updated by ARIA markup
– <button> Yes </button> -> MSAA role of PUSHBUTTON
– <div> Yes </div> -> MSAA role of DIV
– <div role="button“ tabindex=“0” onclick=“...”
onkeyup=“...”> Yes </div> -> MSAA role of
PUSHBUTTON
• Virtual view last items above with screen reader
– Yes Button
18

19. ARIA Examples and Best Practices
Element Behaviors
• ARIA only changes information in the browser’s accessibility
API
• In browser, e.g. the element is still a div and appears as a
div in the DOM
– includes all native div event handlers
– does not visually change
• Developers must implement keyboard and mouse events
– onclick, onkeyup
• May need to implement focus order, indication of focus
– Tabindex=0, CSS outline property
19

20. ARIA Examples and Best Practices
Best Practices
• Use native HTML elements whenever possible
• Implement keyboard accessibility for all users
– Ensure it still works however with screen readers
• Use of ARIA does not take away the need to design
accessible content
– e.g. content must still be visually discernible without color
• Follow the ARIA specification for each component type
• Avoid ARIA hacks to make something work with a particular
AT or browser
• Placement of ARIA markup on ancestors or descendants
may affect support
20

21. ARIA Example and Best Practices
• Use of certain ARIA roles such as “dialog” or “application”
has substantial consequences
• Use of aria-labelledby with multiple labels in IE requires
tabindex="-1" on each label
• Accessible name calculation
– If the control has an aria-label or an aria-labelledby
attribute the accessible name is to be calculated using
the algorithm defined in section 5.2.7. Accessible Name
Calculation of the WAI-ARIA 1.0 specification.
• role="presentation“ – obscure the meaning of the element
• aria-hidden – hide content from AT; keep on screen
Best Practices (cont.)
21

22. ARIA Example and Best Practices
APIs
• Microsoft Inspect – MSAA and UI Automation testing tools
– Properties
– Tree structure
• Microsoft AccEvent – Accessibility event watcher
• AccProbe – Multi-platform accessibility API inspection
DOM
• Firebug Toolbar
• AMP Toolbar for Firefox
• IE Developer Toolbar
• Accessibility Favlets
Testing Tools
22

23. References
• Object Inspector and other MSAA tools
https://www.ssbbartgroup.com/blog/2010/11/08/looking-for-
object-inspector-and-other-msaa-tools/
• 2014 WebAIM Screen Reader Usage Survey
http://webaim.org/projects/screenreadersurvey5/
• Why keyboard accessibility isn’t the same thing as screen
reader accessibility: http://lnkd.in/jYnkZq
• Microsoft Active Accessibility (MSAA)
http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility
• Basic HTML5, ARIA, and Screen Readers
http://www.accessibleculture.org/research-
files/ozewai2011/basic-html5-aria-screenreaders-
presentation.html#(1)
23

24. References
• ARIA Specification
http://www.w3.org/TR/wai-aria/
• ARIA Roles Model
http://www.w3.org/TR/wai-aria/roles
• ARIA User Agent Implementation
http://www.w3.org/TR/wai-aria-implementation/
• HTML to platform level accessibility API
http://www.w3.org/TR/2013/WD-html-aapi-20131001/
• Native HTML Semantics (HTML5 content model)
http://dev.w3.org/html5/spec-LC/content-models.html
24

25. Questions?
25

26. Thank You
Contact Us
Jonathan Avila
Chief Accessibility Officer
jon.avila@ssbbartgroup.com
Bryan Garaventa
Senior Accessibility Engineer
bryan.garaventa@ssbbartgroup.com
SSB Contact Information
info@ssbbartgroup.com
(800) 889-9659
Follow Us
Twitter
@SSBBARTGroup
LinkedIn
www.linkedin.com/company/ssb-bart-group
Facebook
www.facebook.com/ssbbartgroup
Blog
www.ssbbartgroup.com/blog
26