AI Knowledge Hub

How should Product and Engineering build accessibility into a feature?

Quick answer

Build accessibility into a feature by identifying affected users and tasks during discovery, setting testable criteria when shaping, and checking designs and code with automated and manual methods throughout delivery. Product owns the user outcome and priority; Engineering owns technical implementation and verification. Keep a route for reporting and fixing barriers after release.

What to remember

Key takeaways

Research barriers in the actual user journey.
Include accessibility in feature criteria and design reviews.
Automated checks help but do not replace manual and user testing.
Retest changed journeys and keep a route for post-release fixes.

A feature can pass functional tests while a user cannot complete its main task with a keyboard or assistive technology. If accessibility enters only at release, the team may have to redesign a journey under time pressure.

Start with the task and the barrier

Identify who needs to complete the task, which interaction might exclude them and what alternatives they use. Include users with disabilities in research where possible. The question is practical: can people complete the intended outcome? Product, design and Engineering should share the evidence rather than hand a generic checklist to one specialist.

Set criteria while shaping

Current practice often relies on design systems, standards, acceptance criteria and audits. These are valuable, but a compliant component can still sit inside an unusable journey. During feature shaping, state testable behaviour such as keyboard order, meaningful control names, error recovery and content clarity. Review the criteria with an accessibility specialist for high-risk journeys.

Test through delivery

The GOV.UK Service Manual recommends thinking about accessibility from the start and combining automated and manual tests. Those instructions are for UK government services; the general delivery lesson can inform other teams. Engineering can automate detectable checks, while design, testing and users help find interaction and comprehension barriers that tools miss.

Keep ownership after release

Define who examines reported barriers, how urgent defects are prioritised and how regressions are checked when a feature changes. Product weighs the impact on users and business outcomes. Engineering investigates cause, fix and release risk. Do not claim that one test pass proves universal accessibility, and seek local legal advice where a specific compliance claim is needed.

Example

Hypothetically, a travel team adds a booking amendment form. Research finds that some customers use keyboard navigation and may need to correct an itinerary without losing entered data. Product makes completion and recovery part of the feature outcome. Design checks the journey with users; Engineering adds keyboard and error-state tests; the team includes an accessibility review before release and monitors support reports afterwards.

FAQs

Can automated tests cover accessibility?

They catch some code-level issues, but manual checks and research are needed for interaction and comprehension.
Who owns an accessibility defect?

The team needs a named route: Product sets priority from user impact and Engineering owns technical diagnosis and repair.
Should accessibility be checked only before launch?

No. Changed content and behaviour can introduce barriers, so retest affected journeys during maintenance.