The first thing many teams associate with accessibility is colour. "Check contrast in Stark." It matters. But if accessibility work ends there, it's the equivalent of saying health is just about taking vitamins.
Accessibility has multiple layers. Visual is one. The others (auditory, motor, cognitive, neurodivergent) are equally real and, in many cases, more ignored. This post walks through what I usually check beyond contrast.
The visual layer (briefly)
To close the most familiar part first:
- Contrast: minimum 4.5:1 for normal text, 3:1 for large text (WCAG AA). For AAA, 7:1 and 4.5:1. Check with Stark, Contrast Checker, WebAIM.
- Font size: 16px is the comfortable floor for body text. On mobile, more.
- Don't use colour as the only indicator: errors can't be only red; success can't be only green. Pair with text, icon, or pattern.
- Visible focus: always. Keyboard focus must be obvious for anyone navigating without a mouse.
That covers the most immediate visual layer. The rest is where fewer teams arrive.
The auditory layer
Audio in product is growing (notifications, voice UI, embedded videos). Every sound asks for captions, transcripts, or a textual alternative.
- Captions in videos: always. Even for explainer GIFs without narration, consider adding descriptive text below.
- Transcripts: for podcasts, recorded calls, any primary audio.
- Don't rely on sound alone for feedback: a success beep needs a visual equivalent.
- Voice UI: offer a textual alternative whenever possible. Not everyone can or wants to speak in public.
The motor layer
People with tremor, paralysis, wrist injuries, or who use one hand need interfaces that don't demand fine gestures.
- Minimum touch targets: 44×44px (Apple HIG) or 48×48dp (Material). Not less.
- Spacing between targets: 8px minimum. Buttons jammed together produce wrong taps.
- Hover isn't reliable on mobile. Or on tablets. Anything that appears on hover needs a tap alternative.
- Generous or adjustable timeouts. If you have session timeouts or self-advancing animations, give control or warning.
- Drag and drop must have an alternative. Reorder list with arrows, for example.
The cognitive layer
This is where I've focused most lately, because it's where fewer teams think. Cognitive covers: attention difficulties, working memory, language processing, anxiety, neurodivergences.
Practices that work:
- Plain language. Short words, short sentences. No jargon. High Flesch Reading Ease score.
- Predictable structure. Same locations of elements across pages. A brain that struggles to predict tires from inconsistent layouts.
- Reduce cognitive load: show one thing at a time when possible. Wizard steps, not 30 fields on one page.
- Progress indicators: anyone with anxiety benefits from knowing where they are and how much is left.
- Auto-save state. Anyone who gets distracted and closes the tab can't lose everything.
- Confirm destructive actions, but don't confirm everything (noise).
Accessibility for dyslexia (the counterintuitive case)
Something I learned on my team, shared by Rita, who has dyslexia: practices for dyslexia, in some points, contradict general visual accessibility practices.
General accessibility asks for high contrast. For dyslexia, lower contrast helps. Black text on pure white can cause fatigue and make reading harder for people with dyslexia. A dark grey on cream or off-white is, often, more readable.
Other practices:
- Sans-serif fonts, not serif.
- Larger size: 18px+ instead of 16px.
- Slightly larger letter spacing (letter-spacing: 0.02em-0.05em).
- Generous line height (line-height: 1.5+).
- Avoid italics and underlines that distort letter shape.
- Short lines: maximum 60-80 characters per line.
The product solution: offer a reading mode or alternative theme. Don't replace the default.
Screen readers: what makes the most difference
If the product doesn't work with VoiceOver, JAWS, or NVDA, it's exclusionary. The most impactful practices:
- Semantic HTML.
<button>for buttons,<nav>for navigation,<main>for primary content. Don't rely on classes alone. - Alt text on images. Descriptive, not "image of a person".
- Labels on every input. Not placeholders as labels.
- DOM order matches visual order. Read in order, not jumping.
- ARIA when HTML isn't enough, but only then. Bad ARIA is worse than none.
Testing is simpler than it sounds: Mac ships with VoiceOver built in (Cmd+F5). Ten minutes navigating your own product with VoiceOver shows more than any audit checklist.
What to add to your flow
Three concrete actions:
- Add an accessibility rubric to design review, with at least 5 lines: contrast, touch size, non-visual alternative, screen reader, language simplicity.
- Run a monthly VoiceOver test on a flow of your product. Just you, 10 minutes, no formal audit. You'll find things.
- Talk to someone who uses assistive tech. Even a short call. It's worth more than reading 5 articles.
More on the background in the Inclusion and Diversity guide. On the overlap between accessibility and ageing, see The crucial need for designing for ageing. For accessibility in workshops and research, see Making workshops accessible.