On August 1, 2026, WordPress co-founder Matt Mullenweg posted a comment on the Make WordPress Accessibility blog that landed like a grenade in the accessibility community: the Accessibility Team, he said, had “overstepped its authority, usefulness, and charter.” The comment came in response to a routine request from longtime core contributor Joe Dolson to extend the deadline for theme authors to comply with WordPress’s overhauled accessibility-ready guidelines. Mullenweg’s reply wasn’t a negotiation — it was a shutdown. “Actually, this is permanently delayed,” he wrote, and followed up with a line that reset the balance of power inside the project: “Going forward, any other team or committer can override suggestions or requests from current accessibility team members.”
If you run a WordPress site and have never heard of the Accessibility Team, that’s fair — most site owners don’t track internal WordPress governance. But this decision matters well beyond core contributors, because it changes how much you can rely on WordPress itself to keep accessibility standards moving forward. Here’s what happened, what the community did about it, and what it actually means for your site.
What Actually Happened
The immediate trigger was small: theme authors needed more time to meet WordPress’s updated accessibility-ready criteria (the same requirements we covered when the June 30 deadline hit). Dolson asked for an extension — a routine process request. Mullenweg’s response went far past that single question. By declaring the initiative “permanently delayed” and giving any team or committer override power over accessibility recommendations, he effectively stripped the Accessibility Team of the authority it had used for years to set and enforce standards across core and themes.
Separately — and this is the part worth watching closely — Mullenweg has floated the idea of moving accessibility work into a “canonical plugin” rather than keeping it embedded in core development. Canonical plugins are official WordPress.org projects (Akismet and Jetpack are well-known examples) maintained under the WordPress umbrella but developed outside core. On paper, that sounds like a reasonable way to let accessibility work move faster without waiting on core release cycles. In practice, accessibility experts and contributors have pushed back hard, warning that moving accessibility out of core risks turning it into an opt-in feature rather than a baseline expectation — something you have to know to go install, rather than something built into every WordPress site by default.
The Community’s Response: The Accessibility Lab Plugin
Rather than wait for the dust to settle, Automattic-sponsored contributor Anne McCarthy published a prototype a few weeks later: the Accessibility Lab plugin. It’s modeled on the existing Performance Lab and AI Team plugins — an umbrella plugin where individual accessibility “Features” and “Experiments” can be built, tested, and used by anyone, each tagged with a track showing whether it’s headed toward core adoption or intended to stand alone as a practical tool.
McCarthy was careful to draw a boundary around what the plugin is not. In her own words, it is not “install this plugin to have accessibility needs met” or “to make WordPress accessible.” That distinction matters. The Accessibility Lab is a testing ground for features that may eventually reach core — not a finished accessibility solution, and not a substitute for WordPress fixing accessibility problems in core itself. Joe Dolson has given it conditional support, but the reception from the wider community has been mixed, with real concern that a lab plugin becomes a permanent workaround rather than the transitional step it’s meant to be.
Why This Matters If You Just Run a WordPress Site
You don’t need to follow WordPress core politics to feel the effects of this decision. A few practical consequences are already visible:
- Theme accessibility-ready compliance is now less predictable. With the enforcement initiative “permanently delayed,” there’s less certainty about which themes will actually meet accessibility-ready criteria going forward, and less institutional pressure on theme authors to get there.
- Core accessibility fixes may slow down. If any team or committer can override the Accessibility Team’s input, changes that used to move through an accessibility review can now be waved through without one.
- Accessibility features may increasingly live in optional plugins rather than core. That shifts the burden onto site owners to know they need to install something extra — which is precisely the kind of gap that lets inaccessible sites ship by default.
- Your site’s compliance responsibility hasn’t changed at all. ADA, Section 508, and state-level requirements don’t care about WordPress’s internal governance disputes. The legal exposure discussed in Washington’s WCAG mandate and DOJ’s Title II deadlines still applies to you regardless of what core decides to ship.
The Real Lesson: Don’t Wait on Core
This isn’t really a story about internal WordPress drama — it’s a reminder of something that was already true. WordPress core and your theme have never guaranteed an accessible site. Even a fully accessibility-ready theme only covers the theme’s own markup; it says nothing about your content, your images, your forms, or the plugins you’ve layered on top. That gap existed before August 1, and it’s not going away regardless of how the canonical plugin debate resolves.
If anything, this episode is a useful signal that accessibility on WordPress is likely to become more fragmented, not less, in the near term — spread across core, an experimental lab plugin, individual theme decisions, and whatever third-party tools site owners choose to run. That makes it more important, not less, for site owners to have their own way of finding and fixing real accessibility issues instead of assuming WordPress or their theme has it handled.
Take Action
You can’t control what WordPress core decides to prioritize, but you can control what happens on your own site. LEWCA scans your actual WordPress site for real, code-level WCAG issues — not just theoretical gaps in your theme’s accessibility-ready badge — and its accessibility toolbar gives visitors practical tools while you work through fixes. Pro adds AI-powered code fixes, scheduled scanning, and compliance reporting, so you’re not relying on core governance debates to know where you stand. No tool can promise 100% compliance, and we won’t tell you otherwise — but you can see and fix your own site’s real issues today. Check out pricing or download LEWCA to get started.