Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Rob Dodson

May 24, 2017
Tweet

More Decks by Rob Dodson

Other Decks in Technology

Transcript

  1. Accessibility for teams
    Rob Dodson
    @rob_dodson

    View full-size slide

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

    View full-size slide

  3. Accessibility
    For Teams!
    Rob Dodson
    @rob_dodson

    View full-size slide

  4. Hey Rob,

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. Project Manager
    UX Designer
    Developer

    View full-size slide

  8. Project Manager

    View full-size slide

  9. Include accessibility work in
    every milestone.

    View full-size slide

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

    View full-size slide

  11. Everyone should receive training.

    View full-size slide

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

    View full-size slide

  13. 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 full-size slide

  14. Accessibility Fundamentals
    bit.ly/a11y-fundamentals

    View full-size slide

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

    View full-size slide

  16. Identify critical user journeys.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. Incorporate a checklist.

    View full-size slide

  20. 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 full-size 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.
    Vox Accessibility Guidelines
    accessibility.voxmedia.com

    View full-size slide

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

    View full-size slide

  23. 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 full-size slide

  24. Incorporate checklist reviews
    into major milestones.

    View full-size slide

  25. Evaluate product with user studies.

    View full-size slide

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

    View full-size slide





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

    View full-size slide

  28. We tend to design using
    our own biases.

    View full-size slide

  29. Remember, our bodies change.

    View full-size slide

  30. And our context
    can change.

    View full-size slide

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

    View full-size slide

  32. Content has good color contrast.

    View full-size slide

  33. 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 full-size slide

  34. material.io/color

    View full-size slide

  35. leaverou.github.io/contrast-ratio

    View full-size slide

  36. Tab order is identified.

    View full-size slide

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

    View full-size slide

  38. 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 full-size slide

  39. ChromeLens video

    View full-size slide

  40. Controls have accessible labels.

    View full-size slide

  41. 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 full-size slide

  42. ✓ Multiple ways to interact with UI.

    View full-size slide

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

    View full-size slide

  44. Avoid conveying information with color
    alone.

    View full-size slide





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

    View full-size slide

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

    View full-size slide

  47. 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 full-size slide

  48. Tab order is logical.

    View full-size slide

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

    View full-size slide

  50. Not all elements are focusable

    View full-size slide

  51. bit.ly/a11ycasts

    View full-size slide

  52. Focus is properly managed
    and visible.

    View full-size slide

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

    View full-size slide


  54. close

    Menu


    Start
    Contact


    View full-size slide

  55. focus();

    close

    Menu


    Start
    Contact


    View full-size slide

  56. focus();

    close

    Menu


    Start
    Contact


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  60. Focus is properly managed
    and visible.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  66. Interactive elements have
    keyboard support.

    View full-size slide

  67. 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 full-size slide

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

    View full-size slide

  69. 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 full-size slide

  70. 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 full-size slide

  71. bit.ly/a11ycasts

    View full-size slide

  72. ARIA roles & attributes
    applied as needed.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  75. Elements are properly labeled.

    View full-size slide

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

    View full-size slide


  77. 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 full-size slide

  78. 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 full-size slide

  79. 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 full-size slide

  80. Testing is automated.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  89. 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 full-size slide

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

    View full-size slide

  91. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide