Inclusive design in practice: beyond the checklist

Checklists are not enough

WCAG and audit checklists get you to a baseline: keyboard use, contrast, labels, structure [1]Source 1 . That baseline matters. But inclusive design is also about who you consider when you make decisions, and how you keep improving.

If you only fix issues after an audit, you will keep creating new ones. If you only design for people like you, you will miss the people who need your site most.

Who are you designing for?

“Everyone” is not a persona. Inclusive design works when you get specific about the people you might exclude by default.

• Ability: People who use keyboards only, screen readers, magnification, or voice. People with low vision, dyslexia, or cognitive differences. People who are deaf or hard of hearing.
• Context: People on slow or flaky connections, on small screens, in bright sunlight or in a hurry.
• Experience: People who are stressed, unfamiliar with your sector, or not confident with technology.

You do not need to design a separate experience for each group. You need to avoid decisions that accidentally lock them out (e.g. mouse-only interactions, unexplained jargon, video with no captions).

Involve real users

The best way to know if your design works for more people is to include people with different needs and contexts in your process [2]Source 2 .

• Early: Talk to users before you lock in structure and interaction patterns. Simple interviews or task-based sessions can surface barriers you had not thought of.
• With assistive tech: If you can, test with people who use screen readers, magnification, or keyboard-only. You learn where focus goes, what is announced, and what is confusing.
• Ongoing: One round of testing is not enough. Include accessibility and inclusion in your regular review (e.g. when you add a new flow or component).

You do not need a lab. You need a few people, clear tasks, and the willingness to watch and listen.

Build inclusion into decisions

Make inclusion part of how you work, not a separate “accessibility phase”.

• When choosing components: Prefer patterns that are keyboard-friendly, focusable, and announced correctly (e.g. buttons for actions, links for navigation, proper form labels).
• When adding content: Write clear headings and link text; add alt text that describes the image for someone who cannot see it; provide captions or transcripts for video and audio.
• When prioritising: Ask “who might this break for?” before you ship. Fix the biggest barriers first.

For more on what accessibility means in practice, see what accessibility means: a plain language definition and we build accessible sites: show me your process.

Summary

Use checklists to reach a baseline, then go further: get specific about who you might exclude, involve real users (including assistive tech users), and build inclusion into everyday decisions. Inclusive design in practice is ongoing, not one-off.