1 / 26

Understanding ARIA Technology: Enhancing Web Accessibility with Browsers and Screen Readers

Discover the pivotal role of Accessible Rich Internet Applications (ARIA) in web accessibility. This presentation, presented by Jonathan Avila and Bryan Garaventa from SSB BART Group, delves into the innovative features ARIA brings to HTML, enhancing user interaction for people using assistive technology. Learn about the current state of screen reader support, various browsers implementing ARIA, and best practices for incorporating these attributes into web applications. With insights drawn from extensive audits and best practices, this session is geared toward reducing legal risks while improving accessibility.

alair
Télécharger la présentation

Understanding ARIA Technology: Enhancing Web Accessibility with Browsers and Screen Readers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The ARIA Technology Stack: Browsers and Screen Readers Jonathan AvilaBryan 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

  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 View Assistive Technology BrowserView User APIs BrowserControls DOM

  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

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

  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

  17. Screen Reader View • Keystroke Interaction What happens when a key is pressed

  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 WebAIMScreen 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?

  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

More Related