Implementing accessibility is not about fixing a series of issues.

Implementing accessibility is not about fixing a series of issues. It is a capability the product and the organisation must learn to sustain.

An accessibility audit can tell you what is wrong with a product. It cannot prevent a team from creating the same problems again.

The client approached us as the European Accessibility Act deadline was getting closer and they needed a quick diagnosis, a clear understanding of the scope, and fixes.

I already knew the organisation and the product. The application had not previously been developed with accessibility embedded in the product process, so I knew that an audit could address the most immediate problems. Still, it could not be the long-term solution.

I proposed an approach that allowed us to work on both levels at the same time: audit the existing product and move identified issues directly into development sprints, while building the team’s knowledge to maintain accessibility in future releases.

We tested key user journeys across Android and iOS, including navigation, forms, messages, lists, detail views and transactional flows. Validation covered TalkBack, VoiceOver, voice control, keyboard navigation, contrast, text scaling, semantics, accessibility labels and focus behaviour.

An audit gives you a picture of the product at a particular moment

It can tell you that a button does not have the right label, that a screen reader announces an element in a confusing way, or that the focus order is incorrect. But if the team fixes those issues and then returns to the same way of designing, implementing and testing, the next feature can create the same type of barrier.

This is why the question was not only what do we need to fix now? It was also: what needs to happen after the audit so that accessibility does not remain a one-off remediation exercise?

From audit to an accessibility implementation model

The audit was therefore only one part of the approach. In parallel, I developed an accessibility implementation model for the organisation, defining the stages of work, responsibilities across Product Design, development and QA, and a path from remediation towards a practice the team could sustain across future sprints.

The model was:
Audit → remediation plan → education → implementation within sprints → retesting → standards for new features → continuous accessibility maintenance.

Because of the regulatory deadline, these stages could not happen sequentially. Audit, remediation and education partially ran in parallel.

Issues identified during the audit went into a shared working spreadsheet that served both as audit documentation and as actionable material for the team. It included the problem, severity, criteria, testing method and implementation recommendations. This allowed findings to move into development rather than remain in an audit report.

The audit itself also became part of the education process. Working through concrete issues allowed us to explain how semantics and roles work, how visible text differs from an accessibility label, why focus order matters, and which behaviours depend on implementation rather than visual design.

Education was not something planned for after the audit. It was embedded in the work from the beginning.

Accessibility has to become part of product delivery

Fixing existing barriers is the first step. The next is ensuring that accessibility is considered when new features are designed, implemented and tested — before another audit discovers the same classes of problems again.

The implementation model therefore included team education, accessible UI components, accessibility testing within sprints, remediation and retesting, documentation, and maintaining standards as the product evolved.

The objective was not to make the organisation permanently dependent on an accessibility audit. It was to give the people building the product enough knowledge, process and ownership to continue the work themselves.

An accessible handoff is more than flows and mock-ups

A standard design handoff is good at communicating what a user can see. It does not automatically communicate everything developers and testers need in order to implement and validate accessibility.

What should a screen reader call an element? What is its role? In what order should information be announced? How should focus behave? Which message should be announced when the state changes? What is visible UI copy, and what needs to be communicated to assistive technology as an accessibility label?

A handoff to the development and QA team therefore needs to communicate not only flows and screens, but also the intended accessible behaviour of the product.

Later, while continuing my research into this problem, I came across a webinar presenting BrowserStack Accessibility Design Toolkit, a Figma plugin. I subsequently stayed in contact with the BrowserStack team while exploring the solution.

What interested me was how closely the approach corresponded to the problem we had initially solved through our extensive working spreadsheet. The toolkit brings accessibility annotations and requirements closer to the design itself and supports areas such as reading and focus order, roles and ARIA, component checks and developer handoff.

Instead of accessibility knowledge living primarily in a separate audit artefact, much of that information can travel with the design into implementation.

Ultimately, we did not implement this direction in the product, so I cannot claim results from it.

A technical audit cannot replace lived user experience

Another part of the implementation model was a permanent expert group of people with disabilities and people who use assistive technologies in their everyday lives. Its role was intended to be the regular validation of both existing and new functionality.

Our audits and WCAG-based testing can identify accessibility problems, but without testing by people who actually rely on assistive technologies, we cannot fully determine whether a process makes sense to them or whether they can complete their task in the product.

A team can check whether an element has the correct label. A user can tell us whether that label actually helps them understand what to do. We can verify the reading order. Someone who uses a screen reader every day can tell us whether that order makes sense while completing the actual task.

The expert group was not ultimately established and remained part of the proposed implementation model. That distinction matters: technical conformance and validation of the user experience answer different questions. We need both.

Quick fixes do not yet create product capability

Some of the issues identified during the screen-reader audit were implemented within development sprints. During that work, the team was also acquiring knowledge it could use when working with accessibility in the future.

The sprint team subsequently decided to continue independently. With the agreement of the manager and Product Owner, the remaining stages of the programme we had proposed were not continued with our involvement. This illustrates the distinction between fixing identified issues and building a sustainable product capability.

Accessibility capability requires several elements to work together:
ownership + team competence + design and development criteria + accessible handoff + continuous testing + user validation.

An audit can start the process, and quick fixes can improve the existing product, but the real test is the next feature.

If the people who conducted the accessibility audit disappeared from the project tomorrow, would the team still know how to design, implement and validate the next feature as accessible?

Implementing accessibility is not about fixing a series of issues. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.