Section 4 · Prototype to Handoff
Designing for Accessibility
17 min4 min readFill in the blanks
Lesson at a glance
Check Steady’s screens for contrast, color-only meaning, target size, focus order and text resizing, and annotate what developers need so the accessible design survives the build.
- 1Contrast, again, everywhere
- 2Never color alone
- 3Targets big enough for thumbs
- 4Focus order and focus states
- 5Names, labels and text size
No video here — just the real thing: a written lesson, runnable examples, a quiz and practice.
Roughly one in twelve men has some form of color vision deficiency. Many people use phones with larger text, with a screen reader, with one shaky thumb on a bus, or in bright sunlight. None of them are edge cases; together they are a large share of Steady’s users, and most of what helps them makes the app better for everyone.
Accessibility is cheapest at design time. A contrast failure costs a color change in Figma, and much more once it ships across a dozen screens. This lesson walks Steady through the checks Sofia runs before any handoff.
Contrast, again, everywhere
You learned the numbers in Lesson 1.3 and re-checked them in dark mode in Lesson 3.4. Now apply them to the things that are easy to forget:
- Control outlines: an unchecked check circle is only a ring. Against the row surface it needs 3:1, or people cannot find it.
- Focus indicators: the focus ring needs 3:1 against what surrounds it.
- Disabled states: WCAG exempts disabled controls from contrast, but a disabled button nobody can read leaves people unsure what they cannot do. Keep the label legible.
- Text on images or illustrations: measure against the lightest part of the image under the text.
Figma’s contrast checker in the color picker covers individual pairs as you work. On Organization and Enterprise plans, at the time of writing, Check designs can also flag contrast issues across a selection.
Never color alone
Steady’s first design showed a missed habit with a red check circle and nothing else. To someone who cannot distinguish red from teal, every habit looks the same. WCAG’s Use of Color criterion requires that color is never the only way meaning is conveyed.
The fix is a second cue: the Missed variant gets an x icon inside the circle and a “Missed yesterday” caption under the name; Done gets a check mark and the name in the secondary text color. Color still helps, but shape and words carry the meaning. Test it by viewing the screen in grayscale: if you can still tell the states apart, you have passed.
Targets big enough for thumbs
WCAG 2.2 sets a minimum at level AA: interactive targets of at least 24 × 24 CSS pixels, or enough spacing around smaller ones. Platform guidelines go further for comfort: Apple recommends 44 × 44 points, and Material Design recommends 48 × 48 dp. For a phone app, design to the platform guideline.
The visible shape and the tappable area do not have to match. Steady’s check circle stays a 32 px circle visually, but the Check button component is a 44 × 44 frame with the circle centered in it. The frame’s bounds tell developers the real hit area.
Focus order and focus states
People using a keyboard, switch control or a screen reader move through a screen one element at a time. Two design decisions affect them directly.
Focus states. Every interactive component needs a visible focus style, usually a 2 px ring in a color that meets 3:1. Add Focused to the State property of Button, Chip, Text field and Check button, so it exists in the kit, not as an afterthought.
Focus order. The order should follow the visual reading order: on the New habit sheet, that is close, name field, icon picker, frequency chips, reminder toggle, Save habit. Usually developers get this right by default if the layout is logical; when your layout is unusual, annotate the order with numbered markers. Figma’s annotations include an Accessibility category at the time of writing, which keeps these notes separate from spacing specs (Lesson 4.3).
Names, labels and text size
Screen readers announce elements by name. An icon-only add button would be read as “button” unless someone gives it a name, so annotate it: accessible name: “Add habit”. The text field needs a visible label, “Habit name”, not just hint text that vanishes when typing starts.
Finally, remember the 30% larger text test from Lesson 2.4. iOS and Android both let people enlarge text system-wide. Rows built with Hug height and Auto height text grow gracefully; anything with a fixed height clips. Respecting reduced-motion settings belongs here too: annotate a simpler fade as the alternative to your streak celebration.
With the screens checked and annotated, they are nearly ready for developers. Next you hand them off in Dev Mode.
Key takeaways
- Meaning must never rely on color alone; pair color with an icon, text or shape change.
- WCAG 2.2 AA asks for touch targets of at least 24 by 24 CSS pixels, while Apple and Google recommend 44 points and 48 dp, so design to the platform guideline.
- A target’s tappable area can be larger than its visible shape, which lets a 32 px check circle sit inside a 44 px hit area.
- Every interactive element needs a visible focus state, and the focus order should follow the reading order you annotate.
- Icon-only buttons need an accessible name and inputs need visible labels, and both belong in your handoff annotations.