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

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

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

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

Where and how can designers impact accessibility?

Visual Design Content Access Way-finding Interactions

Visual Design

Colors (or colours for the Brits in the room)

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

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

Check color contrast for 
 non-text elements: UI components, graphic objects (3:1 ratio)

Building an accessible color palette from the start

Start with the main color(s)

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

A contrast grid matrix to help define color combinations

Document how they should be used together

What variant of green can be combined for the status?

Text: 
 Resizing and typography

Text resize to 200% without losing content / elements

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

Don’t use fancy special characters Source: Alexa Heinrich

Interactions

Buttons and links

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

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

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)

Documenting link states

Document button states, including focus state

For complex links, document what area is actionable

Forms and inputs

No content

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

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!

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

Complex component interactions

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

Interaction Flows: how should this component work for mouse users

Interactive Flow: mouse and keyboard

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

Wayfinding

In Page Navigation

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

Example of Jira HTML documentation for enterprise App

Skip links

HTML5 section elements and ARIA Landmarks

Document ARIA Landmarks with Include plugin

Headings in the page

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

Reading and focus order for navigation

Reading Order Documentation Example

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

Keyboard navigation: focus order at component level

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

Content Access

Support both portrait and landscape mode

Image, icons, screen reader content

What should the assistive technology announce for those images?

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

Announced text for “icon buttons”

Screen reader alternative to non text information

Video, Audio and moving Content

Captions for videos Audio Podcast Transcript

Provide captions for all live audio content.

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

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.

Who and when can we document all of this?

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

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

๏ 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

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

Determine the best format 
 for and with YOUR team: Jira? Confluence? Word Document? Mockup annotations?

This is NOT a substitute for communicating with people!

It’s a team effort!

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

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

Mapping “who can document what?”

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

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

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

To learn more about accessibility. 1.

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

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

Benefits for the 
 design-developer collaboration

Design documentation helps gain time and avoids misinterpretations. 4.

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

Benefits for everyone else in the team

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

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

Resources

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

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

No content

No content

Some nice toolkits to help you document

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