Design and Development Checks: Contrast, Focus, and Keyboard Navigation Tests
Can people with low vision or motor impairments reliably read and interact with your interface, or do colour choices and hidden focus styles create barriers? Small design and implementation choices can make content usable or render it inaccessible.
This post outlines four practical accessibility checks to use from the start of design and development: measure colour contrast, build accessible colour systems with tokens, design visible focus states, and audit keyboard navigation, focus order, and interactions. Applying these checks early catches accessibility issues sooner, reduces rework, and improves usability for everyone.
What contrast ratios should I aim for in text and UI components?
Aim for a minimum of 4.5:1 for normal text, 3:1 for large text and non-text UI components, and 7:1 to meet AAA; define large text as roughly 18pt regular or 14pt bold so token sizes map to these thresholds.
How should I test colour contrast in real interfaces?
Capture the final rendered screen and sample the actual foreground and immediate background pixels for each state, run a contrast calculator, and record pass or fail for normal, hover, focus, disabled, and active states rather than relying on token values alone.
How do I build an accessible colour system with tokens?
Define semantic paired tokens for foreground and background with attached contrast metadata, create explicit tokens for hover, focus, active, disabled, and inverse states, and automate contrast checks across design files, component libraries, and CI while publishing a concise usage guide and including keyboard-only reviewers.
Why are visible focus states important and how should I implement them?
Visible focus is required by accessibility guidance and must not rely on colour alone, so implement a clear outline, ring, or shadow that meets a 3:1 non-text contrast threshold, prefer :focus-visible with fallbacks, and never remove the native outline without a replacement.
How do I audit keyboard navigation and avoid focus traps?
Run keyboard-only passes with Tab, Shift+Tab, Enter, Space, and arrow keys to confirm logical DOM order and activation keys, avoid positive tabindex values, ensure non-button controls handle Enter and Space, trap focus inside overlays and restore it on close, and validate behaviour with screen readers and high-contrast modes.
How to measure colour contrast to meet WCAG accessibility success criteria
Aim for a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. To meet WCAG AAA, use a contrast ratio of 7:1. Define large text as roughly 18pt regular or 14pt bold so you can map your type sizes to these thresholds. Measure non-text user interface components, such as icons, controls, and focus indicators, against a 3:1 threshold, sampling them against their immediately adjacent colour. These thresholds come from the WCAG accessibility guidelines.
Capture contrast in context. Take a screenshot of the final rendered screen and sample the actual foreground and immediate background pixels for each state. Run a contrast calculator, and record pass or fail for the normal, hover, focus, disabled, and active states rather than relying on token values alone.
When a colour fails, change one variable and re-measure. Practical fixes include darkening or lightening the background, increasing font size or weight, adding a solid or semi-opaque panel behind text, or adding a visible outline to icons.
Test keyboard focus explicitly. Check that focus rings and outlines remain visible on patterned backgrounds and over images to catch common failures.
Build checks into your workflow: add automated contrast tests against design tokens or palettes, keep a simple audit log of failures and fixes, prioritise issues by frequency and user impact, and include a manual in-context sampling step for dynamic content such as overlays and gradients.
How to build accessible colour systems using design tokens
Define semantic colour tokens and publish paired foreground and background aliases, using purpose-driven names such as color-text-primary, color-bg-default, and color-border-strong. For each token, attach contrast metadata that records the token’s contrast ratios against its intended background(s), so designers and engineers can programmatically evaluate combinations.
Aim for WCAG contrast ratios of 4.5:1 for normal text, and 3:1 for large text and non-text UI elements. Automate contrast checks across design files, component libraries, and CI pipelines so failing combinations either flag pull requests or cause builds to fail. Add snapshot tests that assert contrast for each token pairing across common backgrounds to make compliance verifiable.
1. Define explicit tokens for hover, active, focus, disabled, and inverse states rather than generating them on the fly. On-the-fly mixing often creates unpredictable contrast and visual regressions; explicit tokens make behaviour repeatable and testable.
2. Test and record contrast for every state. Log the token pairs that meet accessibility thresholds, and note accepted alternates for unavoidable low-contrast cases (for example, brand text over patterned backgrounds). Having a recorded whitelist prevents accidental use of failing combinations.
3. Run keyboard runs and focus tests during component QA to confirm visible focus indicators, logical tab order, and absence of focus traps. Capture any failures as tickets with screenshots and the exact token pairs that produced the issue so engineers can reproduce and fix them.
4. Validate tokens in real-world conditions: sample them on images, gradients, and layered UI. Automated checks miss interactions that appear only in complex compositions, so visual sampling reduces surprises in production.
5. Simulate common colour-vision deficiencies, such as protanopia and deuteranopia, to reveal problematic combinations that still pass numeric contrast tests but fail perceptually.
6. Publish a concise token usage guide showing accessible examples and unacceptable edge cases. Include keyboard-only reviewers in design reviews to ensure keyboard scenarios make it into acceptance criteria.
Following these steps reduces accessibility regressions, speeds up QA, and gives designers and developers a shared, auditable source of truth for colour and state behaviour.
Design and test visible focus states
Make focus indicators persistent and clearly perceivable. Implement a distinct outline, ring, or shadow that does not rely on colour alone, and check it against adjacent colours to meet non-text contrast requirements. WCAG 2.4.7 requires a visible focus indicator, and WCAG 1.4.11 mandates a minimum 3:1 contrast ratio for non-text contrast. Test indicators under realistic conditions — for example, keyboard-only navigation at 200% zoom and common device scale factors — to confirm thickness, padding, and bounding area remain noticeable. Prefer :focus-visible with accessible fallbacks for browsers that do not support it, never remove the native outline without providing a replacement, and avoid tabindex values greater than 0 to keep tab order predictable.
To verify keyboard accessibility, run structured keyboard-only tests and confirm each interactive control receives focus and can be activated using Tab, Shift+Tab, Enter, Space, and the arrow keys. Check that focus order follows the DOM, and that overlays and modals trap focus while restoring it when closed so users do not lose focus or become trapped.
Test across OS high-contrast and forced-colours modes, confirm behaviour with the prefers-reduced-motion setting, and verify functionality with screen readers and keyboard-only testers. Use automated audits to catch obvious gaps, but rely on manual testing to find focus traps and dynamic focus changes that tools often miss.
How to audit keyboard navigation, focus order, and UI interactions
Run a keyboard-only walkthrough. Tab forwards and backwards, using Tab and Shift+Tab, and watch the focus path. Each interactive control should receive focus in the logical visual order a user expects. Keyboard users and assistive technologies rely on a predictable sequence, so any jumps or omissions will disrupt navigation.
If Tab skips elements, inspect for these common causes: positive tabindex values that re-order the tab sequence, CSS positioning that breaks the DOM order, or hidden overlays stealing focus. Positive tabindex values can produce unpredictable jumps; avoid them where possible.
Validate activation keys. Non-button elements that use role=button must have tabindex=0 and respond to both Enter and Space. Widgets that expect arrow-key navigation should respect left, right, up, and down keys, and pressing Esc should dismiss overlays and modals.
Replace mouse-only event handlers with keyboard equivalents so ARIA roles and custom controls mirror the interaction model of native elements. In short, ensure custom controls behave like their native counterparts so keyboard-only and assistive-technology users get the same, predictable experience.
As you run the walkthrough, ensure the focus indicator is always visible and high contrast. If your custom styles obscure or weaken it, restore visibility with a clear outline, drop shadow, or contrasting background so keyboard users can track focus. For dynamic interfaces, trap focus inside modals and flyouts while they are open, set programmatic focus to the first meaningful control when the overlay appears, and return focus to the control that opened it when the overlay closes to prevent focus loss. Avoid keyboard traps by never using positive tabindex values; prefer tabindex=0 so elements remain in the natural tab order. Finally, implement the full, expected keyboard behaviour for any ARIA role so assistive technologies and keyboard users experience consistent, predictable interactions.