Pragmatic Accessibility. A How-To Guide for Teams.

Pragmatic Accessibility. A How-To Guide for Teams.

Making your site more accessible can be a daunting task. If you are approaching accessibility for the first time, the sheer breadth of the topic can leave you wondering where to start - after all, working to accommodate a diverse range of abilities means there are a correspondingly diverse range of issues to consider. This talk will explain how to effectively review a site for accessibility and how to build accessibility considerations into your team process so each team member knows their role, and has the appropriate training material. The goal is for attendees to walk away with an actionable process which they can immediately use to assess and improve their products' accessibility and overall user experience.

95c3a3b33ea51545229c625bef42e343?s=128

Rob Dodson

May 24, 2017
Tweet

Transcript

  1. None
  2. Accessibility for teams Rob Dodson @rob_dodson

  3. May 18th, 2017 Global Accessibility Awareness Day! #GAAD #io17

  4. Accessibility For Teams! Rob Dodson @rob_dodson

  5. Hey Rob,
 Our team is ramping up on accessibility. Do

    you have any material to help us get started?
  6. Thanks! That's really helpful. But, what about our designers? Do

    you have your project managers do this course?
  7. Accessibility is a team effort. Every person has a role

    to play.
  8. Project Manager UX Designer Developer

  9. Project Manager

  10. Include accessibility work in every milestone.

  11. Everyone should receive training. Identify critical user journeys. Incorporate a

    checklist. Evaluate product with user studies.
  12. Everyone should receive training. ✓

  13. Having one person "own" accessibility doesn't work that well.

  14. This is a headline Followed by a subhead This is

    body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. Web Accessibility by Google bit.ly/web-a11y
  15. Accessibility Fundamentals bit.ly/a11y-fundamentals

  16. Material Guidelines: Accessibility bit.ly/a11y-material

  17. Identify critical user journeys. ✓

  18. "A user can add an item to their shopping cart."

    Primary user journey:
  19. "A user can change their avatar in the settings menu."

    Secondary user journey:
  20. Incorporate a checklist. ✓

  21. This is a headline Followed by a subhead This is

    body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. WebAIM Checklist webaim.org/standards/wcag/checklist
  22. This is a headline Followed by a subhead This is

    body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vox Accessibility Guidelines accessibility.voxmedia.com
  23. Apply the checklist to your primary and secondary user journeys.

  24. Checklist Item 1 Checklist Item 2 Checklist Item 3 Primary

    Use Case 1 Primary Use Case 2 Secondary Use Case 1 Secondary Use Case 2 x x x x
  25. Incorporate checklist reviews into major milestones.

  26. Evaluate product with user studies. ✓

  27. It's possible to make something "accessible" but not very useable.

  28. ✓ ✓ ✓ ✓ Everyone should receive training. Identify critical

    user journeys. Incorporate a checklist. Evaluate product with user studies.
  29. UX Designer

  30. We tend to design using our own biases.

  31. Remember, our bodies change.

  32. And our context can change.

  33. Content has good color contrast. Tab order is identified. Controls

    have accessible labels. Multiple ways to interact with UI.
  34. Content has good color contrast. ✓

  35. Text and icons should aim for a contrast ratios of

    4.5:1 for smaller text and 3:1 for larger text (14 pt bold/18pt regular).
  36. material.io/color

  37. leaverou.github.io/contrast-ratio

  38. Tab order is identified. ✓

  39. Tab order - The order in which elements receive focus

    as the user presses the tab key.
  40. Tab order should follow the order of the visual layout,

    from the top to the bottom of the screen. It should traverse from the most important to the least important item.
  41. None
  42. ChromeLens video

  43. Controls have accessible labels. ✓

  44. Accessible labels should be succinct, and don’t need to include

    the control type or state. Focus on action verbs. 1. Search 2. Voice Search 3. More options 1 2 3
  45. ✓ Multiple ways to interact with UI.

  46. Consider how someone will interact with a control using a

    keyboard instead of a mouse. Plan your focus states.
  47. Avoid conveying information with color alone.

  48. ✓ ✓ ✓ ✓ Content has good color contrast. Tab

    order is identified. Controls have accessible labels. Multiple ways to interact with UI.
  49. Developer

  50. Focus management, semantics, and ARIA combine to form a robust

    experience.
  51. Tab order is logical. Focus is properly managed and visible.

    Interactive elements have keyboard support. ARIA roles & attributes applied as needed. Elements are properly labeled. Testing is automated.
  52. Tab order is logical. ✓

  53. Implicitly Focusable Native elements like input, button, and select get

    focusability for free! Click Me! Password Aisle Seat
  54. Not all elements are focusable

  55. <div class=“menu-btn"></div>

  56. <button class=“menu-btn"></button>

  57. bit.ly/a11ycasts

  58. Focus is properly managed and visible. ✓

  59. When you change the content of the page it's important

    to direct the user's attention by moving focus.
  60. None
  61. <nav> <button>close</button> <header> Menu </header> <ul> <li><a href="#">Start</a></li> <li><a href="#">Contact</a></li>

    </ul> </nav>
  62. focus(); <nav> <button>close</button> <header tabindex=“-1"> Menu </header> <ul> <li><a href="#">Start</a></li>

    <li><a href="#">Contact</a></li> </ul> </nav>
  63. focus(); <nav> <button>close</button> <header tabindex=“-1"> Menu </header> <ul> <li><a href="#">Start</a></li>

    <li><a href="#">Contact</a></li> </ul> </nav>
  64. Sometimes we want to trap or prevent focus from entering

    an area.
  65. None
  66. inert is a new HTML attribute that removes an element

    and its descendants from the tab order and the accessibility tree.
  67. <nav inert> … </nav> <main> … </main>

  68. <nav> … </nav> <main inert> … </main>

  69. Try the polyfill at github.com/wicg/inert

  70. Focus is properly managed and visible. ✓

  71. Focus rings can seem unpredictable, leading a lot of developers

    to remove them with outline: none. This is an anti-pattern!
  72. :focus-ring is a new CSS selector that helps differentiate mouse

    and keyboard focus.
  73. /* override UA stylesheet if necessary */ .fancy-button:focus { outline:

    none; } /* establish desired focus ring appearance */ .fancy-button:focus-ring { outline: 2px solid blue; }
  74. Apply focus states based on modalities or user preference.

  75. Try the polyfill at github.com/wicg/focus-ring

  76. Interactive elements have keyboard support. ✓

  77. This is a headline Followed by a subhead This is

    body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. ARIA Authoring Practices. This is your cheat sheet for component accessibility! w3.org/TR/wai-aria-practices-1.1
  78. ARIA Authoring Practices. This is your cheat sheet for component

    accessibility! w3.org/TR/wai-aria-practices-1.1
  79. Roving tabindex Programmatically move focus in response to key events

    and update the tabindex to reflect the currently focused item. <div tabindex=“-1”>Item 1</div> <div tabindex=“0”>Item 2</div> <div tabindex=“-1”>Item 3</div> Item 1 Item 2 Item 3
  80. <div tabindex=“-1”>Item 1</div> <div tabindex=“-1”>Item 2</div> <div tabindex=“0”>Item 3</div> Item

    1 Item 2 Item 3 focus(); Roving tabindex Programmatically move focus in response to key events and update the tabindex to reflect the currently focused item.
  81. bit.ly/a11ycasts

  82. ARIA roles & attributes applied as needed. ✓

  83. The Authoring Practices Guide will also tell you which ARIA

    attributes to use and when to use them!
  84. ARIA Design Patterns w3.org/TR/wai-aria-practices-1.1

  85. Elements are properly labeled. ✓

  86. Labels help users understand the purpose of a control.

  87. <label> Control must be a child of <label> or targeted

    by an IDRef using the label's for="" attribute. Only works with native form elements. “First name, edit text” <label> First Name: <input type="text"> </label>
  88. aria-label A string to be used as the accessible label.

    Overrides any other native labelling mechanism. <button id="hamburger" aria-label="Main Menu"> </button> “Main Menu, button”
  89. aria-labelledby A reference to an element (or elements) which will

    act as an accessible label. Overrides any other labelling mechanism including aria-label. “Men’s Outerwear, Shop Now, button” <h2 id="lbl">Men's Outerwear</h2> <button id="btn" aria-labelledby="lbl btn"> Shop Now </button>
  90. Testing is automated. ✓

  91. Automated testing with aXe CLI github.com/dequelabs/axe-cli

  92. Lighthouse developers.google.com/web/tools/lighthouse

  93. Lighthouse developers.google.com/web/tools/lighthouse

  94. Lighthouse developers.google.com/web/tools/lighthouse

  95. The (experimental) accessibility panel in Chrome DevTools will help you

    check your work!
  96. Use the new Accessibility DevTools experiment to inspect your elements.

  97. Use the new Accessibility DevTools experiment to inspect your elements.

  98. Use the new Accessibility DevTools experiment to inspect your elements.

  99. Tab order is logical. Focus is properly managed and visible.

    Interactive elements have keyboard support. ARIA roles & attributes applied as needed. Elements are properly labeled. Testing is automated. ✓ ✓ ✓ ✓ ✓ ✓
  100. Accessibility is a team effort. Every person has a role

    to play.
  101. Project Manager Provide team training Identify use cases Incorporate checklist

    into process UX/Designer Understand diverse user needs Design inclusively Developer Manage focus Add keyboard support Include proper semantics
  102. Web Accessibility by Google bit.ly/web-a11y

  103. A fortnightly YouTube series on Web Accessibility bit.ly/a11ycasts

  104. Check out our docs bit.ly/a11y-fundamentals

  105. Material Guidelines: Accessibility bit.ly/a11y-material

  106. thank you! Rob Dodson @rob_dodson Images by Nick Bluth, Julien

    Devaux, Oksana Latysheva, Alena, Dan Lowenstein for the Noun Project