Matt Mullenweg suggested a paid external scanner for checking the accessibility of the WordPress.org and WordCamp sites. He was replying to a Tweet by Amber Hinds about her Accessibility Checker plugin rejected by Samuel Otto Wood and Dion Hulse. 

A Brief History

In November 2023, Alex Stine, the accessibility expert opened a Trac ticket requesting to add Accessibility Checker plugin to .org sites to help content publishers meet basic accessibility guidelines and the community discussed the suggestion in the Slack channel. 

Courtney Robertson (Open Source Developer Advocate at GoDaddy & a dedicated WordPress Training Team Faculty Member) pointed out that “We have precedent of using Jetpack premium, and also Sensei Pro on LearnWP.” She reminded everyone that “This plugin has passed NASA’s criteria, so perhaps it could pass any code reviews here as well?  It’s more of an issue about plugin conflicts and the sort most likely that need a review. This could be especially helpful on sites like Docs, LearnWP, and top level .org sites.  I mean, everywhere too, but focusing on those areas would be fantastic to start.”

Automattic-sponsored Kelly Choyce-Dwan also supported the suggestion “I haven’t heard anyone say they don’t want it or any reasons against it, yet. something could come up in review, though.” Equalize Digital’s CEO Amber Hinds provided a pro version of the plugin to test to Audrey HC-sponsored Samuel “Otto” Wood. 

Later, the issue discussion was picked up by Birgit Olzem (WordPress expert). She wanted to know the status of the ticket in connection with the CloudFest Hackathon.

Otto raised the issue of the plugin using custom tables. “Using your own table will slow our progress down in getting it on org. Dotorg is a very big multi site system with several different database servers. Tables have to be specifically designed to work in it. Using your own tables in a plugin like this requires a lot more. Basically, we use hyperdb, and we will have to modify the settings for that to include the table. Additionally, the plugin can’t create its own tables. We have to create it for them in advance. In short, the plugin seems a heck of a lot more complicated than anything we’d install on dotorg normally.”

Automattic-sponsored Dion Hulse also expressed his doubts about the plugin’s sustainability. “Custom tables are meh, but I understand why they’re used, seemingly needed for an overview dashboard of the entire site or something. One thing I’m not sure about, is how it integrates with the editor – Obviously it’s likely not going to be integrated with the P2/O2 editor, but I don’t know how well it integrates with Gutenberg latest-stable; we’ve seen breakage with some plugins on that. I guess the main thing that jumps out to me is the question of; Is this solving a problem that actually exists, or is it just for prevention of issues?”

“At this stage, I’m not inclined to install this plugin; but I’m not against surfacing accessibility issues that it’s identified (although I expect a number of them will be intentionally discarded, until a redesign of the site/component/etc happens)”, he concluded. 

For those interested, Birgit Olzem has summarized the Slack conversion:

Amber Hinds took to X to share her disappointment over the outcome of the discussions. “It’s clear that neither of the reviewers thinks flagging accessibility problems in the editor is needed.” She checked and found several accessibility issues in the WP.org and some WordCamp sites. “How can we get WordPress contributors, team leads, and WordCamp organizers to check for accessibility every time they write a blog post or add or edit a page? Accessibility testing needs to be second nature, and it can’t just be on the WPAccessibility team.” She tweeted. 

Matt got into the discussion suggesting an external scanner instead of a plugin. “We could pay for an external scanner. I’m not interested in it being built into wp-admin or the publishing process, more something we initiate externally and periodically….An external scanner could get us the goal (improved accessibility) without adding surface area to the code base, including potential security issues if this is not battle tested or well-audited.”, he said.

Amber Hinds shared Siteimprove and Monsido as good options but pointed out that they are pricey and only scans already published content on a weekly basis. 

Owner and CTO of Equalize Digital, Steve Jones, tweeted, “there are external scanners and browser addons but none are going to bring accessibility scans to the editor in real-time as the Accessibility Checker does. These external tools can be successful but they need to be deeply integrated into your publishing/dev workflows.”

We hope the community reaches a decision about accessibility soon, especially in the backdrop of the European Accessibility Act (Directive 2019/882) coming into force on June 28, 2025.