A Designer’s Guide to Documenting Accessibility & User Interactions

Transcript

1. AA
   1
   2
   Stéphanie Walter - stephaniewalter.design - 2023
   Pushing
   accessibility
   with design
   documentation
   

   View Slide

2. Why fix it, when
   you could
   design and
   build it right to
   start with?
   

   View Slide

3. And a lot of accessibility
   issues can be already
   foreseen and prevented
   in the design phase.
   

   View Slide

4. Designer can use design
   documentation to include
   and push accessibility
   earlier in projects.
   

   View Slide

5. Where and how can designers
   impact accessibility?
   

   View Slide

6. Visual Design
   Content Access
   Way-finding
   Interactions
   

   View Slide

7. Visual Design
   

   View Slide

8. Colors
   
   
   (or colours for the Brits in the room)
   

   View Slide

9. Current Page Indicator
   Color is not
   the only visual
   way to convey
   information
   

   View Slide

10. Check color
    contrast ratios for
    texts / background
    (4.5:1 regular / 3:1
    large)
    

    View Slide

11. Check color
    contrast for
    

    non-text elements:
    UI components,
    graphic objects
    (3:1 ratio)
    

    View Slide

12. Building an accessible
    color palette from the
    start
    

    View Slide

13. Start with the
    main color(s)
    

    View Slide

14. Create color
    variations (darker,
    lighter) that can
    work together text
    on background
    

    View Slide

15. A contrast grid
    matrix to help
    define color
    combinations
    

    View Slide

16. Document how
    they should be
    used together
    

    View Slide

17. What variant of
    green can be
    combined for
    the status?
    

    View Slide

18. Text:
    

    Resizing and typography
    

    View Slide

19. Text resize to
    200% without
    losing content /
    elements
    

    View Slide

20. Text resizing designer guidelines
    ๏ Avoid fixed height buttons
    
    
    ๏ Avoid fixed height text boxes with overflow:
    hidden
    
    
    ๏ Adapt layout at larger font size if necessary
    (multiple columns might become one, secondary
    text on the right might go to the next line, etc.)
    
    
    ๏ Maintain hierarchy even with bigger fonts (H1
    titles should be bigger than H2, etc.)
    

    View Slide

21. Don’t use fancy
    special
    characters
    Source: Alexa Heinrich
    

    View Slide

22. Interactions
    

    View Slide

23. Buttons and links
    

    View Slide

24. Link identification
    ๏ Check that color is not the only way to
    identify a link in a block of text from its
    surrounding. The easiest way is to
    underline links in text.
    
    
    ๏ If the color is the only way to identify it,
    it must have a 3:1 contrast ratio with
    adjacent non link text and provide
    additional visual cues on hover
    

    View Slide

25. Seriously,
    

    just, underline the links
    and call it a day!
    🤷
    

    View Slide

26. Link / button purpose &
    consistency
    ๏ “Does the user understand what will
    happen if they click/tap/interact with
    it?”
    
    
    ๏ Avoid “click here”
    
    
    ๏ Use direct action verbs (open, cancel,
    close)
    

    View Slide

27. Documenting
    link states
    

    View Slide

28. Document button
    states, including
    focus state
    

    View Slide

29. For complex
    links, document
    what area is
    actionable
    

    View Slide

30. Forms and inputs
    

    View Slide

31. View Slide

32. Form guidelines
    ๏ Each field has a label
    
    
    ๏ The label is clear and helps understand
    how to fill the field
    
    
    ๏ Help users prevent errors (expected
    format, instructions, mandatory fields, etc.)
    
    
    ๏ Help to recover from errors (errors are
    marked, clear messages, etc.)
    3.3
    

    View Slide

33. Form elements
    Text fields
    Value
    Label
    Value
    Label
    Message
    Value
    Label
    Label
    |
    Label
    Message
    Value
    Label
    Placeholder
    Label
    Message
    Value
    Label
    Placeholder
    Large Medium Small
    Default
    Focus
    Filled
    Readonly
    Error
    Success
    Info
    Label
    Value
    Label
    Value
    Label
    Message
    Value
    Label
    |
    Label
    Message
    Value
    Label
    Message
    Value
    Label
    Placeholder
    Label
    Message
    Value
    Label
    Message
    Value
    Label
    Placeh…
    Label
    |
    Label
    Value
    Label
    Value
    Label
    Message
    Value
    Label
    Label
    Value / Placeholder 16px
    Label 12px
    Value / Placeholder 14px
    Label 12px
    Value / Placeholder 12px
    Label 10px
    Info / error / warning / success 12px
    Info / error / warning / success 12px Info / error / warning / success 10px
    Status of form
    elements: error,
    success, etc.
    
    
    + the color rules!
    

    View Slide

34. Value
    Label
    Value
    Label
    Message
    Value
    Label
    Label
    |
    Label
    Message
    Value
    Label
    Component Usage in the search result page
    to filter out by year range
    Error case: if user enters
    something that is not a year with 4
    digits and if users enters letters in
    that field
    Default
    Focus
    Filled
    Readonly
    Error
    Success
    Value 16px
    Label 12px
    Info / error / warning / success 12px
    201n
    From
    Please enter a year number
    (for example 2022)
    YYYY
    To
    Apply
    Reset
    YYYY
    From
    YYYY
    To
    Apply
    Reset
    Signature Year
    Signature Year
    Document detail
    cases for error
    recovery
    

    View Slide

35. Complex component
    interactions
    

    View Slide

36. Users can navigate and interact
    with all components using
    different pointing and interaction
    devices (mouse, keyboard, etc.)
    

    View Slide

37. Interaction
    Flows: how
    should this
    component work
    for mouse users
    

    View Slide

38. Interactive
    Flow: mouse
    and keyboard
    

    View Slide

39. Archive email
    Complex gesture — swipe right to archive Alternative: Alternative:
    - open the mail details
    - press the “archive” icon at the top
    - long press to show the toolbar
    - then press the “archive” icon at the top
    Alternatives for
    complex
    gestures
    2.5.1
    

    View Slide

40. Wayfinding
    

    View Slide

41. In Page Navigation
    

    View Slide

42. A good page
    ๏ Is unique for each page
    
    
    ๏ Is short and descriptive
    
    
    ๏ Helps users know where there
    are and what they can expect to
    find on that page
    
    
    ๏ Is NOT SEO keyword stuffing
    Image source: Accessiblity Annotation Kit Indeed
    

    View Slide

43. Example of Jira
    HTML
    documentation
    for enterprise
    App
    

    View Slide

44. Skip links
    

    View Slide

45. HTML5 section
    elements and
    ARIA Landmarks
    

    View Slide

46. Document ARIA
    Landmarks with
    Include plugin
    

    View Slide

47. Headings in
    the page
    

    View Slide

48. Headings
    ๏ The label of the heading is is
    descriptive, clear and accurately
    describes the content the follows
    
    
    ๏ Don’t have illogical order (a h2 after a
    h3)
    
    
    ๏ Don’t use paragraphs with bigger font,
    use Hns instead.
    Image source: Accessiblity Annoation Kit Indeed
    

    View Slide

49. Reading and focus order for
    navigation
    

    View Slide

50. Reading Order
    Documentation
    Example
    

    View Slide

51. Keyboard
    navigation:
    focus order
    at page level
    Figma template by the Fluent Design System team of Microsoft
    

    View Slide

52. Keyboard
    navigation:
    focus order at
    component
    level
    

    View Slide

53. Flows to
    document
    interactions
    between
    pages / views
    User Flows
    Screen flow
    

    View Slide

54. Content Access
    

    View Slide

55. Support both
    portrait and
    landscape
    mode
    

    View Slide

56. Image, icons, screen reader
    content
    

    View Slide

57. What should
    the assistive
    technology
    announce for
    those images?
    

    View Slide

58. It’s our job as a
    designer that the
    tools we design offer
    a place for the
    alternative text
    

    View Slide

59. Announced text
    for “icon
    buttons”
    

    View Slide

60. Screen reader
    alternative to
    non text
    information
    

    View Slide

61. Video, Audio and moving
    Content
    

    View Slide

62. Captions for
    videos
    Audio
    Podcast
    Transcript
    

    View Slide

63. Provide captions for
    all live audio content.
    

    View Slide

64. Provide controls for
    audio content that
    starts automatically
    and lasts more than
    3 seconds
    

    View Slide

65. All of those features need to be
    part of the product roadmap and
    be designed.
    

    

    As designers, you can push for
    those to get implemented, from
    the start.
    

    View Slide

66. Who and when can we
    
    
    document all of this?
    

    View Slide

67. I document final & tested
    components / pages, after
    discussion with devs about
    technical feasibility.
    
    
    

    View Slide

68. I usually
    document at
    component
    level
    Checkboxlist with search filter
    Checkboxlist Filters Interaction flow
    We use the checkbox list with no filter at the top where there are seven or less items in the list
    We use the checkbox list with a search filter at the top where there are height or more items in the list
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    DDDDDDD
    CCCCCCC
    BBBBBBB
    BBBBBBA
    AAAAABB
    AAAAAAB
    Apply
    Reset
    Filtered results
    Status (2)
    Status
    Status
    Status Status
    Status (2)
    User can open the filter menu when:
    - they click on it
    - they put the keyboard focus on it
    and hit /
    The reset button becomes active
    once the user checked any box.
    Once user hits the apply button
    (click or tab to focus + enter) the
    filter closes.
    The filter button changes to the
    active filter style.
    The number of active filters is
    shown (N) next to the filter name.
    The filter is also added to the active
    filter list next to the title
    : the next element is
    highlighted.
    : the previous element is
    highlighted.
    If the user hits , this
    element is checked. It still keeps
    the focus highlight untill the user
    focuses another element.
    Label here that goes on 3
    lines because it is too
    long
    Label here
    16px 16px
    32px
    Label here
    Label here
    Label here Label here
    Label here Label here
    

    View Slide

69. ๏ Ask the team for the
    best format and the best
    place to store this.
    
    
    ๏ I currently document
    with annotations and
    detailed specs in
    separate design system
    Sketch pages
    Sometimes I also
    document directly at
    page level when needed
    

    View Slide

70. Another example of
    detailed annotations
    using numbers and
    margin comments
    Image from Karen Hawkins
    

    View Slide

71. Determine the best format
    

    for and with YOUR team:
    Jira? Confluence? Word
    Document? Mockup
    annotations?
    

    View Slide

72. This is NOT a substitute
    for communicating with
    people!
    

    View Slide

73. It’s a team effort!
    

    View Slide

74. Devs / Accessibility
    experts
    Content - UX
    writers / SEO
    QA / Testing
    Design teams
    Product / Project
    Management
    

    View Slide

75. Start with what you, your team
    members are comfortable with.
    Then build upon this base!
    

    View Slide

76. Mapping “who
    can document
    what?”
    

    View Slide

77. Have a place of reference
    that helps understand
    accessibility vocabulary
    and guidelines
    

    View Slide

78. What are the benefits of such
    documentation (aka how do I convince
    my team now)?
    

    View Slide

79. Benefits for myself, as
    designer (and my
    design team)
    

    View Slide

80. To learn more about
    accessibility.
    1.
    

    View Slide

81. It forces me to think about
    different interactions, beyond
    the “static” pixels I am working
    on.
    2.
    

    View Slide

82. A good onboarding tool for
    new designers, especially if
    they don’t know about
    accessibility.
    3.
    

    View Slide

83. Benefits for the
    

    design-developer
    collaboration
    

    View Slide

84. Design documentation
    helps gain time and
    avoids misinterpretations.
    4.
    

    View Slide

85. It helps bring consistency
    to future pages and
    interactions.
    5.
    

    View Slide

86. Benefits for everyone
    else in the team
    

    View Slide

87. Start conversations about
    accessibility within the
    company, encourages them to
    dig further.
    6.
    

    View Slide

88. All of this is about
    communication to build
    better accessible
    products.
    
    
    You don’t need to / can’t
    document everything.
    

    View Slide

89. Resources
    

    View Slide

90. Don’t forget to explain
    the what AA, AAA means.
    

    View Slide

91. Where to find good examples
    of accessible components
    ๏ The ARIA Patterns: example of complex
    accessible components using ARIA
    
    
    ๏ Gov.uk design system is public and its
    components are supposed to be accessible, so
    it’s a nice place to check for inspiration
    
    
    ๏ Inclusive Components is a blog trying to be a
    pattern library. All about designing inclusive
    web interfaces, piece by piece. There is also
    the book Inclusive Components
    
    
    ๏ A Complete Guide To Accessible Front-End
    Components, a big article with tonnes on
    information to make your components more
    accessible
    

    View Slide

92. View Slide

93. View Slide

94. Some nice
    toolkits to help
    you document
    

    View Slide

95. Ressources and links
    ๏ Links in the slides
    
    
    ๏ Accessibility Annotation Examples from Karen Hawkins
    
    
    ๏ Color ratio Matrix tool
    
    
    ๏ Figma - Contrast Grid plugin
    
    
    ๏ WCAG for designers
    
    
    ๏ A11y - Focus Orderer — Plugin for Figma
    
    
    ๏ Fluent Accessibility Notation — Figma
    
    
    ๏ Include—Accessibility Annotations | Figma Community
    
    
    ๏ ARIA Example: One Main Landmark
    
    
    ๏ Reduced motion example on stephaniewalter.design
    
    
    ๏ A11y Annotation Kit — Figma
    
    
    ๏ Accessibility bluelines — Figma
    
    
    ๏ Accessibility Bluelines (Sketch, Adobe XD, Invision Studio)
    
    
    ๏ Authoring Tool Accessibility Guidelines (ATAG)
    

    ๏ More links to help you build and document better
    accessible designs:
    
    
    ๏ Text Resizer - Accessibility Checker
    
    
    ๏ Firefox Accessibility Inspector
    
    
    ๏ Color accessibility: tools and resources to help you design
    inclusive products
    
    
    ๏ Inclusive Components
    
    
    ๏ browsing with a desktop screen reader
    
    
    ๏ browsing with a mobile screen reader
    
    
    ๏ browsing with a keyboard
    
    
    ๏ browsing with speech recognition
    
    
    ๏ How to document the screen reader user experience
    

    View Slide