Turn knowledge into team practice

Start before the interface is built

Discovery and planning should identify supported environments, important user journeys, known barriers, research needs, and acceptance evidence. This prevents accessibility from becoming an undefined request at the end of implementation.

• Name the devices, platforms, browsers, screen readers, and inputs that matter.
• Identify tasks with high frequency, high consequence, or no alternative route.
• Include experienced screen reader users in research where their strategies affect the decision.
• Record accessibility requirements with the same status as other product requirements.
• Assign an owner for unresolved questions.

Make the non-visual interaction explicit

Design work should describe structure, reading order, labels, states, focus movement, announcements, errors, and recovery. A visual mock-up cannot contain all of this information by itself. Use annotations, prototypes, content specifications, and acceptance examples to communicate the intended experience.

• Define headings, landmarks, groups, and relationships.
• Specify control names, roles, states, values, and instructions.
• Describe focus when overlays open, close, or change.
• Write error and status messages before implementation.
• Explain what happens in loading, empty, success, and failure states.

Build and review in small increments

Developers should use native semantics and platform components where possible, then verify the real accessibility model and screen reader output. Designers, content specialists, and testers can review components before complete flows make defects expensive to change.

• Include accessibility behaviour in component documentation.
• Add automated checks for rules that tools can verify reliably.
• Test custom interaction with a keyboard and relevant screen readers.
• Review dynamic states, not only the initial render.
• Keep known platform differences visible to the team.

Release with evidence and ownership

A release decision should use agreed evidence from automated checks, manual compatibility tests, exploratory work, and user research where required. Known limitations need an owner, impact statement, mitigation, and follow-up date. Support teams also need enough context to recognise and route screen reader reports.

Create a learning loop

Accessibility improves when evidence returns to the system. Convert recurring defects into design-system guidance, component fixes, content rules, test cases, training, and product requirements. Measure whether the same barrier appears again instead of counting only completed audits.

Use an accessibility definition of done

A definition of done can make expectations visible without forcing every feature through the same process. Tailor the evidence to the feature's risk and supported environments. A simple content change may need semantic review and automated checks. A new custom widget can require design annotations, keyboard and screen reader tests, multiple states, and research evidence.

• The intended structure, names, states, focus, feedback, and recovery are documented.
• Implementation uses native semantics or explains why a custom pattern is necessary.
• Automated and manual checks pass for the agreed scope.
• Important defects have an owner and user-impact decision.
• Documentation and support information are updated before release.

Include support and maintenance

The work continues after release. Support teams need a route for accessibility reports and enough context to collect devices, versions, commands, and task impact. Product teams should review reports for recurring patterns, verify fixes in the affected environment, and communicate important limitations or workarounds. Platform upgrades and component changes also need regression checks for high-risk journeys.