Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Accessible Rich Internet Applications (ARIA)


Published on

When it comes to accessibility, HTML has many limitations. Luckily, this is where Accessible Rich Internet Applications (ARIA) steps in.

ARIA fills many of the semantic gaps left by the HTML specification and allows developers to create document structures and interactive components that work wonderfully with assistive technologies. In this talk, we'll identify appropriate use cases for ARIA and look at specific examples of common problems that ARIA can help us solve.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Introduction to Accessible Rich Internet Applications (ARIA)

  1. 1. Introduction to Accessible Rich Internet Applications (ARIA) Matt Isner Deque Systems, Inc.
  2. 2. HTML Without ARIA It’s important to keep a few facts in mind: • HTML was designed to help us distribute documents whose content was primarily static • HTML was not designed to form the basis of interactive applications • HTML was released in 1993 © 2016 - All Rights Reserved 1
  3. 3. Accessibility Challenges JavaScript and CSS have made the web more interactive, but pure HTML has a very hard time conveying complex information about dynamic content. For instance: • Dynamic content that updates in remote parts of the page • Interactive widgets whose components change states • Input fields that are labeled by multiple objects • The list goes on… © 2016 - All Rights Reserved 2
  4. 4. © 2016 - All Rights Reserved 3
  5. 5. © 2016 - All Rights Reserved 4
  6. 6. © 2016 - All Rights Reserved 5
  7. 7. © 2016 - All Rights Reserved 6
  8. 8. Benefits of ARIA Using ARIA, we can: 1. Utilize a more extensive vocabulary of semantic roles for common, modern widgets (sliders, tabs, menus, etc.) 2. Control the structure of document and how users can navigate within it 3. Instruct assistive technologies to switch to the appropriate mode for interactive widgets 4. Provide announcements for updates that occur far away from the currently focused object © 2016 - All Rights Reserved 7
  9. 9. How ARIA Works © 2016 - All Rights Reserved 8
  10. 10. The Accessibility Tree © 2016 - All Rights Reserved 9 User agents use the DOM to construct the so-called “Accessibility Tree”. Using ARIA allows you to modify the information in the tree. Each object has the numerous accessibility properties, some specific to the user agent; but the most common are: Name, Role, Value, and State
  11. 11. © 2016 - All Rights Reserved 10
  12. 12. How ARIA Affects Elements ARIA roles WILL • overwrite the element’s default accessibility mapping ARIA roles WILL NOT • change the element’s appearance • change the element’s keyboard behavior • change the element’s mouse behavior • change the element’s focus behavior © 2016 - All Rights Reserved 11
  13. 13. What ARIA Won’t Do Adding ARIA attributes to your elements won’t add any new mouse or keyboard functionality – you need to do that yourself. The standard interactive behavior for most common widgets can be found in the WAI-ARIA Authoring Practices guide. © 2016 - All Rights Reserved 12
  14. 14. Types of ARIA Attributes Roles Used to identify landmarks, document structure, and widgets. States and Properties Used to express dynamic characteristics of an object, or to represent data values associated with the object. © 2016 - All Rights Reserved 13
  15. 15. Examples of ARIA Attributes Landmark Roles: banner, navigation, main, contentinfo, form Document Structure Roles: group, heading, img, list, listitem, presentation Widget Roles: alert, button, checkbox, dialog, grid, menu, menuitem States: aria-checked, aria-disabled, aria-expanded, aria-hidden Properties: aria-describedby, aria-labelledby, aria-required © 2016 - All Rights Reserved 14
  16. 16. Landmark Roles Applying landmark roles to important sections of the page allows users of assistive technology to navigate directly to areas of interest. © 2016 - All Rights Reserved 15
  17. 17. Document Structure Roles: Group Document Structure roles describe structures that organize content in a page. Document structures are not usually interactive. © 2016 - All Rights Reserved 16 Labeled by both “Filter Results” and “Stops”.
  18. 18. Widget Roles: Slider © 2016 - All Rights Reserved 17 The control element needs • role=“slider” • aria-valuemin=“{n}” • aria-valuemax=“{n}” • aria-valuenow=“{n}” • aria-valuetext=“{txt}” • to be focusable Provide a name for the slider using aria-labelledby. Hide the textual representation of the value (in this case “Wednesday”) from assistive technology using aria-hidden=“true”.
  19. 19. Expandable Regions © 2016 - All Rights Reserved 18 aria-hidden=“true”: Indicates whether an object is not visible or perceivable to any user. aria-expanded=“true/false”: Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.
  20. 20. Toggling Expandable Content © 2016 - All Rights Reserved 19 aria-hidden: Indicates whether an object is not visible or perceivable to any user. aria-expanded: Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed. aria-expanded=“false” aria-expanded=“true” aria-hiddenaria-hidden=“true”
  21. 21. Application Regions © 2016 - All Rights Reserved 20 role=“application”: A region declared as a web application, as opposed to a web document. Causes assistive technologies to switch into a mode where key presses that are normally intercepted and interpreted by the AT are instead passed directly to the browser.
  22. 22. Purely Decorative Images © 2016 - All Rights Reserved 21 role=“presentation”: The element’s implicit native role semantics will not be mapped to the accessibility API. For images that convey no meaning and are purely decorative, use both role=“presentation” and alt=“” or else implement the image as a CSS background.
  23. 23. Some ARIA Best Practices © 2016 - All Rights Reserved 22
  24. 24. Prefer Pure HTML © 2016 - All Rights Reserved 23 Use pure HTML whenever possible – you get a lot for free. Add ARIA when HTML is too limiting for your functionality. BETTER: <h2>About</h2> WORSE: <div role=“heading” aria-level=“2”>About</div> BETTER: <button>Cancel</button> WORSE: <a role=“button” href=“#”>Cancel</a> BETTER: <ol> <li>one</li> … </ol> WORSE: <div role=“list”> <div role=“listitem”>one</div> … </div>
  25. 25. Test Against Multiple Platforms © 2016 - All Rights Reserved 24 Support for ARIA and the Accessibility API varies widely among platforms. Create an accessibility support matrix for your site, and test your features against it. Advertise your supported platforms to your users.
  26. 26. Specify Neutral Elements © 2016 - All Rights Reserved 25 Always use role=“presentation” on non-significant, interim elements within complex widgets. An element with role=“tablist” requires children with role=“tab” in order to be correctly interpreted by the Accessibility API. Using role=“presentation” lets us overwrite the default semantic value of the interim <li> elements.
  27. 27. Managing Focus and Tabbing © 2016 - All Rights Reserved 26 If you are manually managing focus in a custom widget, disable naturally focusable elements using the tabindex=“-1”.
  28. 28. Consult the Specification © 2016 - All Rights Reserved 27 Have a question about using a role or ARIA attribute? Consult the spec! – it’s very informative. • • • •
  29. 29. Thank You! © 2016 - All Rights Reserved 28 I’ve been Matt Isner. Email me your questions anytime at