CSUN The ARIA Technology Stack Browsers and Screen Readers


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Some keystroke presses by a screen reader don’t actually interact with the DOM or browser but instead may just pull information from the cached version of the page and return that information to the user without actually passing the keystroke to the browser at all.  This is what occurs in virtual cursor or browse mode.   Other modes (forms mode) just send the keystrokes directly to the browser and then watch for what happens afterwards.  Screen reader need these different modes in order to provide access to page content that is not actionable and otherwise would not be accessible to users who could not see it.
  • CSUN The ARIA Technology Stack Browsers and Screen Readers

    1. 1. The ARIA Technology Stack: Browsers and Screen Readers Jonathan Avila Bryan Garaventa
    2. 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. 3. Agenda • About SSB BART Group • ARIA • DOM and Accessibility APIs • Screen Reader View • ARIA Examples and Best Practices • References 3
    4. 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. 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. 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. 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. 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. 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. 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. 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. 12. DOM and Accessibility APIs Browser AT Interaction Process AT ViewBrowser View DOM APIs Assistive Technology Use r Browser Controls 12
    13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. Questions? 25
    26. 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