Fixing issues reduces the backlog. Preventing them from coming back requires rethinking the way we design, develop and test digital products.
1. Why accessibility issues return after an audit
Imagine someone who uses a screen reader trying to fill out a form. One field does not indicate that it is required and the submit button does not respond as expected. The person tries to understand what is happening, goes back, tries again and eventually gives up.
During an audit, the team identifies the problem, fixes it, and, after some time, the form starts working as expected.
Months later, in a different form within the same application, the same person encounters exactly the same situation.
Meanwhile, the company reports that after the audit was completed, the issues were fixed and the backlog was cleared.
If the issues were resolved, why do they keep coming back? Closing an issue does not necessarily mean that its underlying cause has actually been addressed. Accessibility problems keep coming back when teams fix individual defects but leave the requirements, shared components and testing practices that produced them unchanged.
2. Defects as symptoms of the process
The explanation is often that we fix the symptom without addressing the root cause.
This happens for several common reasons within organizations:
- requirements are not fully defined when they are handed over to the development team;
- the components being used already have issues;
- testing happens too late, when there is little left that can be changed;
- and fixes made in one project do not always become learnings or guidelines for future projects.
From a front-end perspective, I see this frequently: many of the issues that reach me did not actually start in the code.
They started earlier, in a requirement that was not properly defined or in an interface state that nobody documented. They started with a design decision that did not account for all the component's states. Or with a component that had been inherited and already used on three other screens, which I assumed had been validated because it was already in production.
Often, we do not even question a component that already exists. And that is precisely where errors can continue to appear without anyone realizing it.
A clear example: a component that is already in production is reused on a new screen. At first glance, there is no reason to be suspicious, because it already existed, had already been used, and appeared to work well. But during an accessibility review, I discover that one of its states is not properly communicated to a screen reader, that the focus order does not make sense, or that an interaction is not keyboard accessible.
The error is in the code but the failure that allowed that code to be reused so many times may be much further upstream. If the component was never properly validated, every new use multiplies the same failure. Before a shared component is approved for reuse, the front-end developer checks its states and keyboard and screen reader interactions. When we fix a defect in that component, we also review the screens that already use it.
And that has changed the way I look at accessibility in front-end development: not every issue I find in the code actually started in the code.
The same idea appears in the latest episode of Shapify Experiences, through the cases shared by Matthew Luken (SVP Global Programs & Regulatory Affairs; European Partnerships, Senior Vice President at Deque Systems). Rather than looking only at the defects identified in an audit, the examples show what happens when a team takes a step back and tries to understand why those problems continue to be created.
3. What the case of the 27,000 issues teaches us
Luken shares a case in which a team identified 27,000 accessibility issues. At first glance, it looks like the typical scenario: a huge backlog, a team overwhelmed by hundreds or thousands of issues to resolve and a need for additional resources. But the solution was not to increase the team.
In his public account of the U.S. Bank case, Matthew Luken says the team addressed 27,000 WCAG violations in one sprint without adding staff. The change centred on how PDFs were used in the communications process, rather than on fixing each document separately.
The number gets your attention but the most important part of the story lies elsewhere: understanding why those issues were being generated in the first place and changing the process to prevent them from happening again.
Instead of continuing to fix documents individually, the approach was to intervene at the source of the problem. This is where the difference between fixing and solving becomes clear: fixing thousands of issues reduces the backlog; solving the process that continues to generate those issues prevents the backlog from growing again.
There is another point to consider: the numbers in a report do not always represent everyone affected.
According to Luken, a significant proportion of people who encounter a barrier may simply give up without leaving any record for the team. Therefore, a clean backlog does not necessarily mean that the experience is accessible; it may simply indicate that there are no reported issues.
Among those people could be exactly the person we mentioned at the beginning of this article: the one who gave up on the form without anyone knowing why.
4. How to prevent accessibility issues at the source
Teams can reduce recurring accessibility defects by defining accessible requirements, validating shared components and testing interactions during development.
Understanding where problems originate is only the first step. If they can be introduced at different points in the process, prevention also needs to start earlier.
This is the perspective we find in the cases discussed by Matthew Luken and Nelson Rodrigues, which point to changes that can be applied throughout the entire process, from defining requirements to testing.
Include accessibility in requirements
The toggle example is a good starting point.
If a requirement simply says “add a toggle”, important information is missing for the people who will design, develop, and test that functionality.
- What states exist?
- How is the current state communicated?
- What happens when it receives focus?
- How does someone using a keyboard activate it?
- How does a screen reader identify whether it is on or off?
In practice, there is no need to create a separate accessibility process, but rather to make the requirement complete.
An acceptance criterion that considers the different interface states, for example, selected/unselected or open/closed, can prevent a crucial decision from being left to be discovered only during testing.
Work with accessible and reusable components
This may seem like an obvious decision, but it can be one of the most difficult to implement.
Luken refers to the case of a team that insisted on having its own address component because they considered it different from the others. In the end, the only difference was the rounded corners of the field.
There was no need to create a new component. The existing one simply needed to be adjusted.
This type of decision has a direct impact on accessibility because every duplicated component is a new opportunity to introduce an error that has already been fixed somewhere else.
When an accessible component is fixed at the source, that fix benefits every experience that uses it. If every team creates its own version, the same issue can reappear repeatedly.
Test during development, not just at the end
Automation also plays an important role.
In Deque’s accessibility coverage study, automated tests identified an average of 57.38% of the issues in the study sample. Additional guided tests increased average coverage to 80.39%. These figures describe Deque’s methods and sample; they are not a detection rate for every product or tool.
Automation can identify specific accessibility issues, such as insufficient colour contrast, but it cannot assess whether content is organised in a way that is logical and meaningful to users. It can identify an incorrect ARIA attribute, but it cannot necessarily understand whether the interaction is truly understandable to someone using assistive technology. It can check certain code patterns, but it does not replace the experience of navigating an application using a keyboard or screen reader.
That is why, even with automation, we still need someone to analyze the results and confirm the issue.
Use automated checks during development, then test the interactions that require human judgement.
The earlier an issue is identified, the earlier it can be fixed and, more importantly, the easier it is to determine whether there is a common cause that needs to be addressed at the source.
5. The goal is not to have a zero accessibility backlog
It is tempting to measure accessibility success by the number of issues found and fixed. It is easy to quantify: we had 500 issues, fixed 400 and were left with 100. Then, finally, we reached zero.
But there is a more important question: how many issues are we creating while fixing the previous ones?
If the same components continue to be reused with the same errors, if requirements continue to arrive incomplete, and if accessibility is only validated at the end, the backlog can start growing again as soon as we begin developing the next feature.
Accessibility maturity, therefore, is not just about the ability to fix problems. It is also about the ability to understand why they happen and intervene in the process to prevent them from recurring.
From a front-end perspective, this means looking beyond the error that appears in the code and understanding what caused it. Was it an implementation issue? Was something missing from the requirement? Had the component never been validated? Did the design fail to account for that state? Did the test fail to consider that scenario?
The answers help us understand where we need to intervene. And that is an important difference: instead of simply fixing the problem in front of us, we try to understand what we can change so that the same problem does not happen again.
The goal, therefore, is not just to accelerate the fixing of accessibility issues. It is to create fewer issues in the first place.
And this is precisely the change behind the cases discussed by Matthew in the latest episode of Shapify Experiences. To see how teams put this approach into practice, listen to the Shapify Experiences episode with Matthew Luken and Nelson Rodrigues.
If this is also an issue in your organization, it is worth continuing the conversation.