Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

ARIA Gone Wild

  1. 1. ARIA Gone Wild! Jared Smith @jared_w_smith webaim.org
  2. 2. ARIA n. A solo vocal piece with instrumental accompaniment, as in an opera.
  3. 3. Accessible Rich Internet Applications
  4. 4. why aria?
  5. 5. weaknesses in html
  6. 6. dynamic content updates
  7. 7. soware-like interactions in web apps
  8. 8. complex web applications
  9. 9. aria is sexy and cool
  10. 10. aria allows us to build accessibility into modern web applications today
  11. 11. aria does not solve all accessibility issues
  12. 12. “How do I download aria?”
  13. 13. aria is simply markup roles, states, and properties <div role=”main”>
  14. 14. aria does not change browser functionality or visual appearance
  15. 15. aria changes and enhances native html semantics aria always wins
  16. 16. most answers are in the specification using WAI-ARIA in HTML
  17. 17. aria is supported* by nearly all modern browsers, screen readers, and scripting libraries *support varies
  18. 18. you can only make your content more accessible by using aria you lose nothing by using it now (if done correctly)
  19. 19. when shouldn’t i use aria?
  20. 20. when native html will get the job done Bad: <img src="submit.jpg" onclick=...> OK: <a onclick="..."><img src="submit.jpg"... Better: <a role="button" onclick="..."> <img src="submit.jpg"... Best: <button onclick="...">
  21. 21. aria landmarks
  22. 22. application, banner, complementary, contentinfo, main, navigation, form, and search <ul role=”navigation”> <div role=”main”> <form role=”search”>
  23. 23. you can (but don’t have to) label multiple landmarks of the same type to differentiate them <ul role=”navigation” aria-label=”main navigation”> <div role=”navigation” aria-labelledby=”catHeading”> <h2 id=”catHeading”>Categories</h2>
  24. 24. don’t overdo it
  25. 25. adding aria just because you can is a slippery slope
  26. 26. typically only one per page: banner, contentinfo, and main
  27. 27. avoid orphaned content put everything in a landmark
  28. 28. the end of “skip” links?
  29. 29. screen reader “freakout” mode when an element that has focus or is being read is modified or destroyed
  30. 30. screen reader “freakout” mode can be controlled by allowing manual control of updates, setting focus with javascript, aria live regions, aria alerts, etc.
  31. 31. learn the power of tabindex=0 and tabindex=-1 learn the dangers of tabindex=1+
  32. 32. role=”alert” read me right now regardless of focus also alertdialog
  33. 33. role=”presentation” hides roles of elements and most descendants from assistive technology <table role=”presentation”> will should not hide default roles of navigable elements
  34. 34. role=”application” forms mode vs. reading mode
  35. 35. application or forms mode causes screen reader keystrokes to be sent to the browser/application standard screen reader shortcuts are disabled
  36. 36. <body role=”application”> makes it very difficult to manually move out of application/forms mode
  37. 37. some aria elements (tree view, slider, table, tabpanel, dialog, toolbar, menus, etc.) have an assumed application role
  38. 38. test without a mouse ... and test without a mouse in a screen reader screen readers change keyboard interaction behavior
  39. 39. follow the aria design patterns
  40. 40. program esc key to cancel dialogs, menus, etc.
  41. 41. aria-required=”true” not necessary if it’s intuitive that the field is required does not change functionality, only semantics
  42. 42. aria-invalid=”true” identify broken or errant form fields
  43. 43. let css do the heavy liing you change semantic attributes, let css handle styling [aria-invalid=true] { border : 2px solid red; }
  44. 44. aria-disabled=”true” disabled=”disabled” in html removes object from keyboard flow and have extremely poor contrast aria-disabled=”true” allows it to remain in the keyboard flow, but be presented as disabled.
  45. 45. aria-hidden=”true” hides element and all descendants child elements can’t be unhidden [aria-hidden=true]{ display:none; }
  46. 46. aria-labelledby overcomes html’s 1-to-1 label to form control limitation
  47. 47. Name Age Weight Verl 24 145 Ethel aria-labelledby=“row2header ageheader”
  48. 48. aria-haspopup indicate that a link or button triggers an in-page dialog or sub-menu
  49. 49. aria-expanded indicate the status of expandable elements should usually be placed on the link or button that controls the expansion
  50. 50. ... and much, much more... role=”menu” role=”tree” role=”grid” role=”slider” role=”progressbar” role=”tooltip” role=”tabpanel” aria-live aria-grabbed etc. Authoring Practices document provides interaction models and design patterns http://www.w3.org/WAI/PF/aria-practices/
  51. 51. sometimes things fail, even if you’ve followed the specification screen reader testing is vital support is improving
  52. 52. wcag 2.0 techniques do not yet include much aria focus on accessibility, not just compliance
  53. 53. html5 mappings <div> <div role=”main”> <main role=”main”> <main> <input> <input aria-required=”true”> <input required>
  54. 54. the future is html5
  55. 55. thank you Jared Smith @jared_w_smith webaim.org

×