Every engineering team has a backlog, and every backlog has items that keep getting deprioritized in favor of something else. Accessibility issues are frequent casualties of this pattern, logged correctly after an audit or a user report, assigned a low priority, and quietly pushed from sprint to sprint for months or years, not because anyone decided accessibility does not matter, but because it never quite becomes the most urgent thing on anyone's list on any given week. This is an extremely common, almost universal pattern in software organizations. It is also, from a legal exposure standpoint, close to the worst possible position a company can be in.
The reason is not intuitive to most product and engineering teams, who tend to think of "we know about it and it's on the roadmap" as meaningfully better than "we had no idea." Legally, it is close to the opposite. A company that never tested its site and genuinely did not know about a barrier has, at minimum, an argument around lack of actual knowledge. A company with a ticket, a date, an assigned owner, and a paper trail showing it knew about a specific accessibility barrier and chose not to fix it for an extended period has handed a plaintiff's attorney the single most useful piece of evidence that exists in this kind of case: documented, dated proof of knowledge.
The Pattern That Matters Legally: Courts and regulators consistently treat documented knowledge of a barrier, combined with a failure to remediate within a reasonable time, as a significantly stronger basis for liability than an undocumented, undiscovered issue, because it removes any good-faith-ignorance argument entirely.
Why This Pattern Is So Common
The root cause is rarely indifference. It is that accessibility bugs, unlike most severity-one bugs, frequently do not break anything visibly for the majority of people reviewing a sprint board. A checkout bug that crashes for every user gets fixed immediately because it is undeniable and urgent to everyone who sees it. A keyboard trap that only affects users who cannot use a mouse, or a missing alt text pattern that only affects screen reader users, competes for the same sprint capacity against features and bugs that visibly affect the majority of the team's own daily testing experience, and consistently loses that competition unless a deliberate policy exists to prevent it from losing.
This is compounded by how accessibility issues typically get discovered: an audit, often run once, produces a long list of findings all at once, overwhelming a team's normal bug-triage capacity and encouraging batch deprioritization of everything that is not an emergency, rather than the steady trickle of individually-discovered-and-immediately-fixed bugs that most other categories of defect follow.
What "Reasonable Time to Fix" Actually Means Legally
There is no universally fixed legal deadline, like exactly ninety days, that applies across every situation, unlike some regulatory cure periods discussed elsewhere on this site, such as the specific ninety-day window in Italy's AgID enforcement process. In the absence of a specific statutory cure period, courts generally look at whether a defendant acted with reasonable diligence once a barrier was identified, and a documented, unexplained multi-year delay with no evidence of active remediation work is a materially worse position than a documented, actively-in-progress remediation effort with a clear timeline, even if the underlying barrier has technically not been fixed yet in either case. The distinguishing factor is not perfection. It is demonstrable, ongoing good faith effort versus documented inaction.
The Practical Trap of "It's On the Roadmap"
A ticket that exists but has sat untouched for an extended period, with no work logged against it, is, in practice, indistinguishable from a company that never intended to fix the issue at all, from the outside perspective a court or plaintiff's attorney will actually see. Internal intent, "we really did plan to get to this," carries very little legal weight without a corresponding, visible pattern of actual remediation activity: commits, deployed fixes, a documented prioritization decision with a defensible rationale, not just a ticket's continued existence in a backlog.
This connects directly to the pattern covered in our piece on what 'tester standing' means for your website: whatever uncertainty exists around who can sue over a given barrier, a documented, known, unfixed barrier removes the one defense, genuine lack of knowledge, that might otherwise have been available regardless of standing questions, making the underlying fix far more valuable than any procedural defense.
What Actually Changes the Calculus
The fix is not treating every accessibility finding as a same-day emergency, which is not realistic for most engineering organizations and not necessary for most findings. It is building an actual, documented, time-bound remediation process the moment an issue is identified, one that shows continued, visible progress rather than silent deferral, and prioritizing based on real user impact and legal risk rather than treating every accessibility finding as uniformly low priority by default. A findings list with dated remediation commitments and a visible completion trend is a fundamentally different legal artifact than the same list sitting untouched a year later, even before every item on it is actually closed.
If your organization has an accessibility audit sitting in a backlog with findings that have not moved in months, that gap is worth closing with an actual remediation plan, not just acknowledging it exists. Our team can help prioritize and track that work in a way that demonstrates real, documented progress. Reach us at experts@wcag.world, or review ADA.gov's web guidance and current ADA Title III litigation tracking for the broader legal backdrop this pattern sits within.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: we audited 50 accessible websites 47 failed.
For the next review, use these related resources: request the relevant WCAG review.