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

A Designer’s Guide to Documenting Accessibility & User Interactions

A Designer’s Guide to Documenting Accessibility & User Interactions

Full presentation here: https://stephaniewalter.design/blog/a-designers-guide-to-documenting-accessibility-user-interactions/

Accessibility is unfortunately still an afterthought on many projects. User interaction and accessibility requirements are poorly documented, at best. Or forgotten, when handing over designs to developer teams. And fixing it later costs a LOT more than building it right to begin with. Great documentation helps teams implement accessibility requirements the right way. I will tell you why, what and how designers can document different aspects of accessibility and user interactions requirements, to build better more inclusive products.

Stéphanie Walter

August 30, 2023
Tweet

More Decks by Stéphanie Walter

Other Decks in Design

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. Where and how can designers
    impact accessibility?

    View full-size slide

  6. Visual Design
    Content Access
    Way-finding
    Interactions

    View full-size slide

  7. Visual Design

    View full-size slide

  8. Colors


    (or colours for the Brits in the room)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. Check color
    contrast for

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

    View full-size slide

  12. Building an accessible
    color palette from the
    start

    View full-size slide

  13. Start with the
    main color(s)

    View full-size slide

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

    View full-size slide

  15. A contrast grid
    matrix to help
    define color
    combinations

    View full-size slide

  16. Document how
    they should be
    used together

    View full-size slide

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

    View full-size slide

  18. Text:

    Resizing and typography

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

  22. Interactions

    View full-size slide

  23. Buttons and links

    View full-size 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 full-size slide

  25. Seriously,

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

    View full-size 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 full-size slide

  27. Documenting
    link states

    View full-size slide

  28. Document button
    states, including
    focus state

    View full-size slide

  29. For complex
    links, document
    what area is
    actionable

    View full-size slide

  30. Forms and inputs

    View full-size slide

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

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

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

  34. Complex component
    interactions

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. Interactive
    Flow: mouse
    and keyboard

    View full-size slide

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

  39. In Page Navigation

    View full-size slide

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

  41. Example of Jira
    HTML
    documentation
    for enterprise
    App

    View full-size slide

  42. HTML5 section
    elements and
    ARIA Landmarks

    View full-size slide

  43. Document ARIA
    Landmarks with
    Include plugin

    View full-size slide

  44. Headings in
    the page

    View full-size slide

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

  46. Reading and focus order for
    navigation

    View full-size slide

  47. Reading Order
    Documentation
    Example

    View full-size slide

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

    View full-size slide

  49. Keyboard
    navigation:
    focus order at
    component
    level

    View full-size slide

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

    View full-size slide

  51. Content Access

    View full-size slide

  52. Support both
    portrait and
    landscape
    mode

    View full-size slide

  53. Image, icons, screen reader
    content

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  56. Announced text
    for “icon
    buttons”

    View full-size slide

  57. Screen reader
    alternative to
    non text
    information

    View full-size slide

  58. Video, Audio and moving
    Content

    View full-size slide

  59. Captions for
    videos
    Audio
    Podcast
    Transcript

    View full-size slide

  60. Provide captions for
    all live audio content.

    View full-size slide

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

    View full-size slide

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

  63. Who and when can we


    document all of this?

    View full-size slide

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


    View full-size slide

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

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

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

    View full-size slide

  68. Determine the best format

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

    View full-size slide

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

    View full-size slide

  70. It’s a team effort!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  73. Mapping “who
    can document
    what?”

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  77. To learn more about
    accessibility.
    1.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  80. Benefits for the

    design-developer
    collaboration

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  83. Benefits for everyone
    else in the team

    View full-size slide

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

    View full-size slide

  85. All of this is about
    communication to build
    better accessible
    products.


    You don’t need to / can’t
    document everything.

    View full-size slide

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

    View full-size slide

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

  88. Some nice
    toolkits to help
    you document

    View full-size slide

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