Accessibility Regression: Why a Site That Passed Once Won’t Stay That Way
Quick answer: a site that fixes every finding from an accessibility audit doesn’t stay fixed by default. Three separate mechanisms push it back toward failure without anyone touching the code that was flagged: WCAG itself grows over time (2.1 added 17 new success criteria on top of 2.0, 2.2 added 9 more, and conformance to the newer version requires meeting the older ones too), the industry-wide error rate is trending up rather than down (WebAIM’s Million 2026 report found a 10.1% year-over-year increase in errors per page, and — on a separate measure — the share of home pages with any detected WCAG failure rose to 95.9%, reversing six straight years of small improvement on that measure), and the specific thing most strongly correlated with that increase — third-party JavaScript and ad networks — is exactly what e-commerce sites add continuously after launch. None of that requires a developer to break anything on purpose.
This article covers technical accessibility practice, not legal advice — it explains why accessibility conformance drifts over time and how to catch it, not whether a specific site carries legal risk.
An audit is a snapshot of one moment, not a guarantee
A WCAG 2.1 AA audit — automated scanning plus a manual review — answers one question precisely: does this site, as it exists right now, meet this standard, as it’s defined right now? Both halves of that sentence are more unstable than they look.
“As it’s defined right now” moves because WCAG itself isn’t a fixed target. The W3C’s own WCAG overview states plainly that “later versions add new success criteria, and do not change existing success criteria” — WCAG 2.0 shipped December 2008, WCAG 2.1 added a new guideline and 17 additional success criteria in June 2018, and WCAG 2.2 added 9 more in October 2023. The versions are deliberately backwards compatible — content conforming to 2.2 also conforms to 2.1 and 2.0 — but that compatibility runs one direction only. A site that was fully WCAG 2.1 AA compliant the week before WCAG 2.2 shipped didn’t do anything wrong, and also didn’t automatically meet the new standard the week after. SC 2.4.11 Focus Not Obscured, SC 2.5.7 Dragging Movements, and SC 2.5.8 Target Size are all 2.2 additions a 2.1-era audit had no reason to check.
“As it exists right now” moves for a more mundane reason: the page a scanner looked at in January usually isn’t the same page a shopper loads in July. New product templates ship. A marketing team adds a promo banner, a reviews widget, a chat bubble, a size-chart modal, an urgency-countdown timer. Each of those is new markup that an audit from before it existed never evaluated.
The industry-wide trend is getting worse, not better
It would be a reasonable guess that accessibility quietly improves over time as the practice matures — more awareness, more tooling, more lawsuits as a forcing function. The actual data says otherwise, at least for the most recent year measured. WebAIM’s Million 2026 report — an automated scan of the home pages of the top one million sites, run annually since 2019 — found that detected errors per page “increased 10.1% since the 2025 analysis which found 51 errors/page.” Separately, the same report found that 95.9% of home pages had at least one detected WCAG 2 failure, up from 94.8% in 2025 — “reversing a trend of small improvements each of the previous 6 years.” Two different measures from the same report, both moving the wrong direction after years of slow progress.
The report doesn’t leave the “why” to speculation. It ties the increase directly to two causes that scale with exactly the kind of growth an e-commerce storefront experiences: “a significant increase in home page complexity and ARIA code,” and third-party code. On the latter, the report states that “the presence of nearly all of these popular JavaScript libraries was associated with an increase in detected accessibility errors,” and specifically on advertising: “pages that utilized most of these popular ad systems had more errors on average than pages that did not utilize ad networks. The data suggest that ads were among the strongest harbingers of accessibility errors.”
None of that is about a developer breaking something that used to work. It’s about what happens when a site keeps adding things — which is the normal, healthy state of a growing storefront, not a sign of negligence. A chat widget, a reviews platform, a retargeting pixel, and an A/B-testing script are all things a store adds to grow revenue, and each one is a piece of someone else’s code running on your page that your last audit never saw.
Even the automated check itself changes
It isn’t just the standard and the page that move — the tooling evaluating both changes too. A
concrete, in-house example: SC 4.1.1 Parsing, which used to require every id attribute on a page
to be unique, was formally removed from WCAG in the 2.2
revision — the W3C’s own
guidance now treats it as automatically satisfied by any HTML page. In step with that, axe-core
deprecated and disabled its plain duplicate-id rule by default, keeping only the narrower
duplicate-id-aria check (duplicate IDs that are actually referenced by an ARIA attribute or
label). A scan that would have flagged a repeated id on a templated product card two years ago
runs clean today, on the exact same markup, because the rule set underneath it changed — not
because the underlying bug (a broken aria-labelledby reference resolving to the wrong product)
stopped existing. A site can regress relative to an older rule set, hold steady relative to the
current one, and still have a real, user-facing accessibility bug sitting in a template that
renders dozens of times per page.
What this means in practice, without a fear-based number attached
There’s no WCAG-mandated re-test interval, and no credible source that publishes one — so this article won’t invent one. What the sourcing above does support is a set of concrete triggers worth treating as “re-check this,” rather than waiting for a fixed calendar date:
- A new WCAG version ships. 2.1 to 2.2 added nine success criteria that an older audit never evaluated; whenever the next version lands, the same gap opens again for anyone who doesn’t re-check against it.
- A new template, widget, or third-party script goes live. Per WebAIM’s own data, this is the single factor most strongly correlated with new errors — not a hypothetical risk, the thing their scan actually measured.
- A platform or theme update changes generated markup. Shopify, WooCommerce, and most theme frameworks ship updates on their own schedule, not yours; a markup change you didn’t author can still land on your site.
- Enough time and catalog growth has passed that nobody can say with confidence what’s changed. If none of the above triggers is trackable at a given store, that absence of visibility is itself the reason to check periodically rather than never.
FAQ
Does passing an accessibility audit mean the site stays compliant indefinitely? No. It means the site met a specific standard’s specific requirements as of the date it was checked. Nothing in WCAG, or in how real sites change after launch, makes that status permanent.
Is this just a way to sell a subscription? The underlying mechanisms — WCAG’s additive version history, WebAIM’s measured year-over-year error increase, and axe-core’s own rule-set changes — are all independently verifiable from the sources linked above, not something this article is asserting on its own authority. What you do with that information, including whether a paid re-check makes sense for your site, is a separate decision from whether the underlying case is real.
Do automated scanners catch regressions on their own? Partially, and inconsistently. As the duplicate-ID example above shows, a rule set can get narrower over time even as a real bug persists — a clean automated re-scan isn’t proof nothing changed, only proof nothing the current rule set is configured to catch changed.
Get checked again, not just checked once
Quietramp’s $890 audit pairs an automated scan with a human-verified WCAG 2.1 AA review and a prioritized, developer-actionable PDF report. The optional $99/month tier exists for the reason this article lays out: sites keep changing after the first report ships, the standard itself keeps growing, and the tooling checking both keeps changing its own rules — so a single check, however thorough, has a shelf life. See a real sample report or check pricing.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.
Quietramp is an AI-operated agency with human oversight — this article was drafted by our Content/SEO writer role.