Skip to main content
Next Step PM
Back to the library

Design · Core

Design for accessibility and inclusion from the start

Designing for people with disabilities and different circumstances from the start is cheaper than fixing it later, and it usually makes the product better for everyone. In many countries it is also a legal duty.

About 1-3 daysChanges yearlyLast reviewed 5 November 2026

Who this applies to

Skills it builds
Design and user experience
PM types
All
Product types
All
Starting points
All
Ways of working
All
Experience
All
Size of organisation
All

Steps, by experience

Beginner (under 1 year)

  1. Find out which accessibility standard applies to you. Most organisations aim for WCAG 2.2 level AA.
  2. Think about who might be excluded: people with visual, hearing, motor or cognitive impairments, and people with temporary limits, low confidence, poor connections or older devices.
  3. Check the designs for colour contrast, text size, clear labels, keyboard use and plain language.
  4. Make sure nothing relies on colour alone, sound alone or precise mouse movements.
  5. Include disabled people in your usability testing.
  6. Write accessibility requirements into the user stories so they are built and tested.

Intermediate (1 to 4 years)

  1. Agree the accessibility standard and build its checks into design reviews.
  2. Identify excluded groups and design for the hardest cases first.
  3. Test with disabled users and assistive technologies.
  4. Add accessibility acceptance criteria to stories.

Experienced (5+ years)

  1. Make inclusion a product principle with an owner, not a final check.
  2. Use a design system with accessible components to make the right thing the easy thing.
  3. Track accessibility issues as product quality debt and report on them.
  4. Plan for legal duties in each market you serve.

Who can do this

Owner: Product manager

Can be delegated to

  • UX Designer: Check the designs against the accessibility standard
  • Content Designer: Check language, labels and error messages are plain and clear
  • Frontend Engineer or Full-stack Engineer: Confirm designs can be built accessibly and flag issues
  • User Researcher: Recruit disabled participants for testing

Reviewed by: QA / Tester, Policy / Legal / Compliance

Tool examples

Figma
Use a contrast checker plugin and annotate focus order and screen reader labels on the designs.
Miro
Build persona spectrums showing permanent, temporary and situational versions of each limitation.
Jira
Add accessibility criteria to the definition of done so every story includes them.
Claude
Paste your page copy and ask it to rewrite it in plain English at a reading age of about nine, then review the result.

Definition of done

  • Accessibility standard agreed
  • Designs checked for contrast, labels, keyboard use and plain language
  • Disabled users included in testing
  • Accessibility criteria added to user stories

Common pitfalls

  • Leaving accessibility to testing at the end
  • Treating automated checks as enough
  • Only thinking about permanent disabilities

If you lead the team

What good looks like: Accessibility and inclusion are designed in from the start and checked throughout.

Ask your PM

  • How have we included disabled users in design and testing?
  • Which accessibility standard are we meeting?

Warning signs

  • Accessibility is a test at the end.
  • No disabled users have been involved.

Do these first

Sources