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

1. View Slide

2. Accessibility for teams
   Rob Dodson
   @rob_dodson
   

   View Slide

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

   View Slide

4. Accessibility
   For Teams!
   Rob Dodson
   @rob_dodson
   

   View Slide

5. Hey Rob,

   Our team is ramping up on
   accessibility. Do you have any
   material to help us get started?
   

   View Slide

6. Thanks! That's really helpful.
   But, what about our designers?
   Do you have your project managers
   do this course?
   

   View Slide

7. Accessibility is a team effort.
   Every person has a role to play.
   

   View Slide

8. Project Manager
   UX Designer
   Developer
   

   View Slide

9. Project Manager
   

   View Slide

10. Include accessibility work in
    every milestone.
    

    View Slide

11. Everyone should receive training.
    Identify critical user journeys.
    Incorporate a checklist.
    Evaluate product with user studies.
    

    View Slide

12. Everyone should receive training.
    ✓
    

    View Slide

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

    View Slide

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
    

    View Slide

15. Accessibility Fundamentals
    bit.ly/a11y-fundamentals
    

    View Slide

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

    View Slide

17. Identify critical user journeys.
    ✓
    

    View Slide

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

    View Slide

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

    View Slide

20. Incorporate a checklist.
    ✓
    

    View Slide

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
    

    View Slide

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
    

    View Slide

23. Apply the checklist to your primary
    and secondary user journeys.
    

    View Slide

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
    

    View Slide

25. Incorporate checklist reviews
    into major milestones.
    

    View Slide

26. Evaluate product with user studies.
    ✓
    

    View Slide

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

    View Slide

28. ✓
    ✓
    ✓
    ✓
    Everyone should receive training.
    Identify critical user journeys.
    Incorporate a checklist.
    Evaluate product with user studies.
    

    View Slide

29. UX Designer
    

    View Slide

30. We tend to design using
    our own biases.
    

    View Slide

31. Remember, our bodies change.
    

    View Slide

32. And our context
    can change.
    

    View Slide

33. Content has good color contrast.
    Tab order is identified.
    Controls have accessible labels.
    Multiple ways to interact with UI.
    

    View Slide

34. Content has good color contrast.
    ✓
    

    View Slide

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

    View Slide

36. material.io/color
    

    View Slide

37. leaverou.github.io/contrast-ratio
    

    View Slide

38. Tab order is identified.
    ✓
    

    View Slide

39. Tab order - The order in which
    elements receive focus as the
    user presses the tab key.
    

    View Slide

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.
    

    View Slide

41. View Slide

42. ChromeLens video
    

    View Slide

43. Controls have accessible labels.
    ✓
    

    View Slide

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
    

    View Slide

45. ✓ Multiple ways to interact with UI.
    

    View Slide

46. Consider how someone will interact with
    a control using a keyboard instead of a
    mouse. Plan your focus states.
    

    View Slide

47. Avoid conveying information with color
    alone.
    

    View Slide

48. ✓
    ✓
    ✓
    ✓
    Content has good color contrast.
    Tab order is identified.
    Controls have accessible labels.
    Multiple ways to interact with UI.
    

    View Slide

49. Developer
    

    View Slide

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

    View Slide

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.
    

    View Slide

52. Tab order is logical.
    ✓
    

    View Slide

53. Implicitly Focusable
    Native elements like input,
    button, and select get
    focusability for free!
    Click Me!
    Password
    Aisle Seat
    

    View Slide

54. Not all elements are focusable
    

    View Slide

55. 
    

    View Slide

56. 
    

    View Slide

57. bit.ly/a11ycasts
    

    View Slide

58. Focus is properly managed
    and visible.
    ✓
    

    View Slide

59. When you change the content
    of the page it's important to
    direct the user's attention by
    moving focus.
    

    View Slide

60. View Slide

61. 
    close
    
    Menu
    
    
    Start
    Contact
    
    
    

    View Slide

62. focus();
    
    close
    
    Menu
    
    
    Start
    Contact
    
    
    

    View Slide

63. focus();
    
    close
    
    Menu
    
    
    Start
    Contact
    
    
    

    View Slide

64. Sometimes we want to trap or
    prevent focus from entering
    an area.
    

    View Slide

65. View Slide

66. inert is a new HTML attribute
    that removes an element and its
    descendants from the tab order
    and the accessibility tree.
    

    View Slide

67. 
    …
    
    
    …
    
    

    View Slide

68. 
    …
    
    
    …
    
    

    View Slide

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

    View Slide

70. Focus is properly managed
    and visible.
    ✓
    

    View Slide

71. Focus rings can seem
    unpredictable, leading a lot of
    developers to remove them with
    outline: none.
    This is an anti-pattern!
    

    View Slide

72. :focus-ring is a new CSS selector
    that helps differentiate mouse
    and keyboard focus.
    

    View Slide

73. /* override UA stylesheet if necessary */
    .fancy-button:focus {
    outline: none;
    }
    /* establish desired focus ring appearance */
    .fancy-button:focus-ring {
    outline: 2px solid blue;
    }
    

    View Slide

74. Apply focus states
    based on modalities or
    user preference.
    

    View Slide

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

    View Slide

76. Interactive elements have
    keyboard support.
    ✓
    

    View Slide

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
    

    View Slide

78. ARIA Authoring Practices. This is your cheat
    sheet for component accessibility!
    w3.org/TR/wai-aria-practices-1.1
    

    View Slide

79. Roving tabindex
    Programmatically move focus in
    response to key events and
    update the tabindex to reflect
    the currently focused item.
    Item 1
    Item 2
    Item 3
    Item 1
    Item 2
    Item 3
    

    View Slide

80. Item 1
    Item 2
    Item 3
    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.
    

    View Slide

81. bit.ly/a11ycasts
    

    View Slide

82. ARIA roles & attributes
    applied as needed.
    ✓
    

    View Slide

83. The Authoring Practices Guide
    will also tell you which ARIA
    attributes to use and when to
    use them!
    

    View Slide

84. ARIA Design Patterns
    w3.org/TR/wai-aria-practices-1.1
    

    View Slide

85. Elements are properly labeled.
    ✓
    

    View Slide

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

    View Slide

87. 
    Control must be a child of
    or targeted by an IDRef using the
    label's for="" attribute. Only works
    with native form elements.
    “First name, edit text”
    
    First Name:
    
    
    

    View Slide

88. aria-label
    A string to be used as the
    accessible label. Overrides any
    other native labelling mechanism.
    aria-label="Main Menu">
    
    “Main Menu, button”
    

    View Slide

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”
    Men's Outerwear
    aria-labelledby="lbl btn">
    Shop Now
    
    

    View Slide

90. Testing is automated.
    ✓
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

95. The (experimental) accessibility
    panel in Chrome DevTools will
    help you check your work!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

100. Accessibility is a team effort.
     Every person has a role to play.
     

     View Slide

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
     

     View Slide

102. Web Accessibility by Google
     bit.ly/web-a11y
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

106. thank you!
     Rob Dodson
     @rob_dodson
     Images by Nick Bluth, Julien Devaux, Oksana
     Latysheva, Alena, Dan Lowenstein for the Noun Project
     

     View Slide