26
The ARIA Technology Stack: Browsers and Screen Readers Jonathan Avila Bryan Garaventa
| Date post: | 28-Mar-2015 |
| Category: |
Documents |
| Upload: | ashlyn-hillyer |
| View: | 219 times |
| Download: | 5 times |
The ARIA Technology Stack: Browsers and
Screen ReadersJonathan Avila
Bryan Garaventa
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
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
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.)
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
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
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
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
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
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
12
DOM and Accessibility APIs
Browser AT Interaction Process
AT ViewBrowserView
DOM APIs
Assistive Technology
User
BrowserControls
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
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
Screen Reader View
Example
Visited link Need Help?
Register: Complete all fields in the form.
Name
Name Edit
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
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
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
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
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
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.)
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
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 Surveyhttp://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)
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
25
Questions?
Thank You
Contact UsJonathan Avila
Chief Accessibility Officer
Bryan Garaventa
Senior Accessibility Engineer
SSB Contact Information
(800) 889-9659
Follow UsTwitter@SSBBARTGroup
LinkedInwww.linkedin.com/company/ssb-bart-group
Facebookwww.facebook.com/ssbbartgroup
Blogwww.ssbbartgroup.com/blog
26
