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.

Transcript

1. AA 1 2 Stéphanie Walter - stephaniewalter.design - 2023 Pushing accessibility with design documentation
2. Why fix it, when you could design and build it right to start with?
3. And a lot of accessibility issues can be already foreseen and prevented in the design phase.
4. Designer can use design documentation to include and push accessibility earlier in projects.
5. Where and how can designers impact accessibility?
6. Visual Design Content Access Way-finding Interactions
7. Visual Design
8. Colors (or colours for the Brits in the room)
9. Current Page Indicator Color is not the only visual way to convey information
10. Check color contrast ratios for texts / background (4.5:1 regular / 3:1 large)
11. Check color contrast for 
 non-text elements: UI components, graphic objects (3:1 ratio)
12. Building an accessible color palette from the start
13. Start with the main color(s)
14. Create color variations (darker, lighter) that can work together text on background
15. A contrast grid matrix to help define color combinations
16. Document how they should be used together
17. What variant of green can be combined for the status?
18. Text: 
 Resizing and typography
19. Text resize to 200% without losing content / elements
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.)
21. Don’t use fancy special characters Source: Alexa Heinrich
22. Interactions
23. Buttons and links
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
25. Seriously, 
 just, underline the links and call it a day! 🤷
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)
27. Documenting link states
28. Document button states, including focus state
29. For complex links, document what area is actionable
30. Forms and inputs
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
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!
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
35. Complex component interactions
36. Users can navigate and interact with all components using different pointing and interaction devices (mouse, keyboard, etc.)
37. Interaction Flows: how should this component work for mouse users
38. Interactive Flow: mouse and keyboard
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
40. Wayfinding
41. In Page Navigation
42. A good page <title> ๏ 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
43. Example of Jira HTML <title> documentation for enterprise App
44. Skip links
45. HTML5 section elements and ARIA Landmarks
46. Document ARIA Landmarks with Include plugin
47. Headings in the page
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
49. Reading and focus order for navigation
50. Reading Order Documentation Example
51. Keyboard navigation: focus order at page level Figma template by the Fluent Design System team of Microsoft
52. Keyboard navigation: focus order at component level
53. Flows to document interactions between pages / views User Flows Screen flow
54. Content Access
55. Support both portrait and landscape mode
56. Image, icons, screen reader content
57. What should the assistive technology announce for those images?
58. It’s our job as a designer that the tools we design offer a place for the alternative text
59. Announced text for “icon buttons”
60. Screen reader alternative to non text information
61. Video, Audio and moving Content
62. Captions for videos Audio Podcast Transcript
63. Provide captions for all live audio content.
64. Provide controls for audio content that starts automatically and lasts more than 3 seconds
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.
66. Who and when can we document all of this?
67. I document final & tested components / pages, after discussion with devs about technical feasibility.
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 <enter> / <space> 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 <keydown>: the next element is highlighted. <keyup>: the previous element is highlighted. If the user hits <space>, 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
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
70. Another example of detailed annotations using numbers and margin comments Image from Karen Hawkins
71. Determine the best format 
 for and with YOUR team: Jira? Confluence? Word Document? Mockup annotations?
72. This is NOT a substitute for communicating with people!
73. It’s a team effort!
74. Devs / Accessibility experts Content - UX writers / SEO QA / Testing Design teams Product / Project Management
75. Start with what you, your team members are comfortable with. Then build upon this base!
76. Mapping “who can document what?”
77. Have a place of reference that helps understand accessibility vocabulary and guidelines
78. What are the benefits of such documentation (aka how do I convince my team now)?
79. Benefits for myself, as designer (and my design team)
80. To learn more about accessibility. 1.
81. It forces me to think about different interactions, beyond the “static” pixels I am working on. 2.
82. A good onboarding tool for new designers, especially if they don’t know about accessibility. 3.
83. Benefits for the 
 design-developer collaboration
84. Design documentation helps gain time and avoids misinterpretations. 4.
85. It helps bring consistency to future pages and interactions. 5.
86. Benefits for everyone else in the team
87. Start conversations about accessibility within the company, encourages them to dig further. 6.
88. All of this is about communication to build better accessible products. You don’t need to / can’t document everything.
89. Resources
90. Don’t forget to explain the what AA, AAA means.
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
94. Some nice toolkits to help you document
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