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 – –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 View Browser View DOM APIs Assistive Technology User 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 browsers 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 shouldnt 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 KeyEnter/SpacebarArrowsLettersMulti-key keystroke Virtual View Call click eventMove to next unit in Virtual view Perform quick navigation, command, or nothing Sent to page Forms Mode Sent to page 17

18. ARIA Examples and Best Practices Code Example API name, role, state, or value are updated by ARIA markup – Yes -> MSAA role of PUSHBUTTON – Yes -> MSAA role of DIV – Yes -> 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 browsers 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.aria-labelaria-labelledby5.2.7. Accessible Name CalculationWAI-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/ 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/ http://webaim.org/projects/screenreadersurvey5/ Why keyboard accessibility isnt the same thing as screen reader accessibility: http://lnkd.in/jYnkZqhttp://lnkd.in/jYnkZq Microsoft Active Accessibility (MSAA) http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility 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) 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