Skip to main content

Accessibility as Foundation: Inclusive Design Best Practices

Accessibility isn't a feature you add at the end. It's a design constraint that improves the product for everyone when built in from the start — like structural engineering for a building. This guide covers how to embed accessibility into your workflow at every phase, from research through delivery.

Last updated: 22 March 2026

The case for foundation-level accessibility​

When accessibility is an afterthought, it's expensive and fragile. You discover issues late, patches are cosmetic, and the next feature release breaks them. When accessibility is foundational, it's cheap and durable — because the architecture supports it from day one.

Foundational accessibility also produces better designs overall. Constraints breed creativity. Designing for screen reader compatibility forces clear information hierarchy. Designing for keyboard navigation produces logical, predictable flows. These are benefits for all users, not just those with disabilities.

Accessibility in research​

Start your research planning with accessibility in mind:

Include participants with disabilities​

Recruit participants who use assistive technology: screen readers, switch controls, magnification, voice input. Even 1–2 participants per round dramatically improves your understanding of real barriers. Compensation should account for the extra time and effort these participants often invest.

Document assistive technology setups​

Note which screen reader, browser, and OS combination each participant uses. Behaviour varies significantly across setups (NVDA on Chrome vs. VoiceOver on Safari). Your usability test script should include setup documentation.

Observe, don't assume​

Don't guess how someone with a disability uses your product. Watch them. You'll discover workarounds, friction points, and capabilities you didn't anticipate.

Field Note

A visually impaired participant once navigated a form faster than sighted participants by using heading jumps in their screen reader — but only because the heading hierarchy was correct. When we tested a version with broken heading levels, their speed dropped by 60%. Structure matters.

Accessibility in design​

Colour and contrast​

Use a minimum 4.5:1 contrast ratio for body text, 3:1 for large text and UI components. Never rely on colour alone to convey information — add icons, patterns, or text labels. Test your palette with a colour blindness simulator.

Typography and spacing​

Set a comfortable base font size (16px minimum), generous line height (1.5), and adequate spacing between interactive elements. The CSS sizing and spacing guide covers these principles in depth. Users who magnify content need layouts that don't break at 200% zoom.

Focus states​

Every interactive element needs a visible focus indicator. The default browser outline is functional but often too subtle. Design a custom focus ring that's high-contrast and clearly visible. Test it against your background colours.

Touch targets​

Minimum 44×44 CSS pixels for touch targets, with adequate spacing between them. This benefits motor-impaired users, users with large fingers, and anyone using a small screen.

Motion and animation​

Respect prefers-reduced-motion. Provide alternatives for animations that convey information. Never auto-play video without controls. Movement should enhance comprehension, not serve as decoration.

Accessibility in development​

Semantic HTML​

Use the right element for the job: <button> for actions, <a> for navigation, <nav> for navigation landmarks, <main> for primary content. Semantic markup gives assistive technology the information it needs without extra ARIA.

ARIA (when semantic HTML isn't enough)​

ARIA attributes supplement semantic HTML for complex components: tabs, accordions, dialogs, live regions. Follow the "first rule of ARIA": don't use ARIA if a native HTML element does the job. When you do use ARIA, test thoroughly — incorrect ARIA is worse than no ARIA.

Keyboard navigation​

Every interactive element must be reachable and operable with keyboard alone. Tab order should follow visual reading order. Modal dialogs need focus trapping. Multi-step flows need clear focus management. The navigation patterns guide covers keyboard patterns for complex navigation structures.

Form accessibility​

Labels must be programmatically associated with inputs (using for/id or wrapping). Error messages must be linked to the relevant field with aria-describedby. Required fields must be indicated both visually and programmatically. See the forms pattern guide for comprehensive form accessibility patterns.

Accessibility in QA​

Automated testing​

Run automated tools (axe, Lighthouse accessibility audit) on every page. These catch about 30–40% of issues — mostly markup, contrast, and missing attributes. Use the heuristic review tool as a complementary manual check.

Manual testing​

  • Keyboard-only navigation. Unplug the mouse and complete every core task.
  • Screen reader testing. Test with at least two screen readers (e.g., NVDA + VoiceOver).
  • Zoom testing. Set browser zoom to 200% and verify layout integrity.
  • Reduced motion. Enable prefers-reduced-motion and verify animations are suppressed.

Regression prevention​

Add accessibility assertions to your test suite. A heading hierarchy test, a missing-alt-text test, and a focus-order test are high-value low-effort additions.

Building team capability​

Accessibility isn't one person's job. Build capability across the team:

  • Design reviews should include an accessibility pass (use the accessibility checklist).
  • Developer onboarding should include a screen reader basics session.
  • QA checklists should include the manual tests listed above.
  • Sprint retrospectives should flag accessibility issues found late as process failures.

Common mistakes​

Treating accessibility as a separate track. If accessibility work lives in a separate backlog, it gets deprioritised. Integrate it into every story's definition of done.

Over-relying on automated tools. They're useful but incomplete. A page can pass every automated check and still be unusable with a screen reader.

Designing for one disability. Accessibility covers vision, hearing, motor, cognitive, and neurological needs. Don't optimise for screen readers while ignoring motor impairments.

Assuming accessibility means ugly. Accessible designs can be beautiful. The constraint forces clarity, not blandness.

Fixing accessibility after launch. Retrofitting is 10× more expensive than building it in. Start at the foundation.

Checklist​

Related Resources