WordPress co-founder Matt Mullenweg has suggested that accessibility improvements could be developed as a canonical plugin to help contributors respond more quickly to the needs of users who rely on assistive technologies.

The idea, floated in March in the #core-committers channel on WordPress Slack, is part of a broader push to explore canonical plugins: community-developed plugins maintained in close alignment with core and intended to deliver widely requested features.

In response to questions from The Repository, Mullenweg said the suggestion was not about scaling back accessibility in WordPress core, but about enhancing it.

“I have always been deeply committed to accessibility as a core component of WordPress products,” he said. “The idea of a canonical accessibility plugin isn’t about diminishing our commitment to accessibility at the core, but rather enhancing it.”

“Such a plugin could allow us to deliver specialized accessibility improvements and features faster than the core release cycle permits. This approach would enable us to be more responsive to the evolving needs of users who rely on assistive technologies, while maintaining strong accessibility standards in the WordPress ecosystem.”

But accessibility experts say the proposal raises serious concerns — both about what it could mean in practice and what it signals about WordPress’s values.

“Any feature that is available only as a plugin is fundamentally secondary,” said Joe Dolson, a WordPress core committer and accessibility expert. “Being in a plugin sends a clear message that the feature is something that only some users will need, and that those users will know what they need and how to get it. If we want to truly democratize publishing, then that means providing everybody with equal access.”

Dolson said Mullenweg’s comment reminded him of a similar suggestion made in a 2022 Make post, which proposed an “alternative API-based admin designed for accessibility and simplicity.” While this latest proposal was light on detail, Dolson said it triggered concerns that accessibility might be sidelined or treated as an optional experience.

He outlined several potential paths such a plugin could take, from selectively replacing inaccessible features to layering JavaScript-based overlays on top of the existing interface, but said only one of them might be feasible or ethically supportable.

“The only viable path is selectively replacing features. For example, swapping out the table block for a more accessible version,” he said. “But anything involving overlays is fragile, labor-intensive, or potentially harmful, especially when you’re trying to guess context.”

Amber Hinds, CEO of Equalize Digital, said the plugin proposal could potentially introduce unnecessary complexity and risk, especially for a project already stretched thin on contributor resources.

“Maintaining a separate canonical plugin to add ‘accessibility’ to WordPress would be problematic from multiple sides,” she said. “Either we’re removing and replacing components when the plugin is activated, meaning every component has to be built twice, or we’re adding some sort of JavaScript overlay. This will decrease admin performance and could be very prone to breaking.”

Hinds said plugin developers would also be affected, needing to test compatibility both with and without the accessibility plugin — a scenario she described as “a ton of unnecessary work” when accessibility could be built into core from the start.

“Accessible code is quality code, and, frankly, accessibility features benefit everyone,” she said. “Accessibility testing, like browser or mobile testing, should be treated as standard — not optional.”

Rian Rietveld, a web accessibility specialist and former WordPress Accessibility Team rep, also raised concerns.

“Accessibility isn’t just something you add like an extra afterwards,” she said. “It’s a fundamental part of the frontend code, like responsiveness or the WordPress Coding Standards.”

Rietveld warned the plugin approach could create duplication and maintenance issues, and said separating accessibility into a plugin could leave disabled users without access to core functionality.

“If core changes, the accessibility plugin needs to change too. Who will do that work, and how will it be funded?” she asked. “That will look really bad on WordPress. The legislation worldwide gets stricter.”

Both Rietveld and Dolson stressed that accessibility work is already under-resourced and often slowed by the need to avoid breaking existing designs or functionality.

“There are cases where a plugin might let us ship changes that would otherwise break backwards compatibility,” Dolson said. “But what would actually be better for accessibility is to ship those changes in core.”

The proposal comes at a time when WordPress core is scaling back to one major release per year, with project leadership citing corporate pullback and limited capacity. Dolson noted that the idea of a canonical plugin-based approach seemed tied to that reduction in contributor availability — but warned that without clear direction or resources, it could quickly become difficult to manage.

“No one’s been formally consulted about this yet,” he said. “There’s a general feeling [among core contributors] that it’s not a good direction to pursue. Regardless of the ethical considerations, I don’t think there’s a great deal of practicality to it either.”

Hinds also warned that de-prioritizing accessibility in core could hurt WordPress’s ability to serve public sector and enterprise users, especially as global laws increasingly require accessible admin interfaces.

“If large entities cannot use WordPress and choose to use a CMS that handles accessibility better, that’s going to result in fewer contributors and less innovation over time,” she said.

She pointed to the World Wide Web Consortium (W3C) as a cautionary example. In 2023, the W3C selected Craft CMS—not WordPress—to power its next-generation website. Accessibility was a key factor in that decision.

“That’s a big deal,” Hinds said. “Laws around the world increasingly require website accessibility and not just for the front end, for the admin too. If we want WordPress to remain relevant and widely adopted, accessibility has to be built into the foundation, not added on later.”

Image credit: WordCamp Europe.