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.

Transcript

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.
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.
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.
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