A Model for WordPress Accessibility

I am going to propose a way to increase the overall accessibility of the WordPress ecosystem. It requires acknowledging some mistakes and using those as the base for building a better platform.

I long for a world where a metric for featuring #WordPress themes and plugins in the repo is #Accessibility.

WordPress runs at a level that sets a large-scale precedent for how the web is built. We publish the code that people copy and paste. We can do better.

Current Situation

If you want an accessible WordPress theme, you can go to the WordPress.org theme directory and look for themes with the accessibility-ready tag. As of today, there are 105 themes available (assuming its problematic infinite scroll showed me all of them).

The theme review process is slow. It is made up of volunteers who typically already have other commitments with WordPress. With other accessibility tasks in WordPress, the team is already stretched too thin with (what I believe is) a backlog of themes to review.

Even with an accessible theme and careful work by site authors to keep the content and custom styles accessible, all it takes is one plug-in to throw the accessibility efforts out the window.

The theme review team does not have the bandwidth to also take on plug-in review. Plug-in review requires some different skills than theme review, which means the team also needs a deeper bench. It also cannot be done with automated tools, making the process that much more difficult to kick-start. Even if it could, there is the challenge of setting up an environment and staying on top of plug-in updates.

Gutenberg As Lesson

One thing that Gutenberg did well is show us where there are systemic deficiencies in the overall process for building accessible features into WordPress. We saw the outcome of the process in the 329 page Gutenberg accessibility audit, detailing poor decisions that came from two years of dismissing experts and its own commitment to WCAG.

We learned that no organization can ignore accessibility and get away with it. We also know that Automattic devoted 40 employees to Gutenberg, all while expecting accessibility professionals to donate their own time and expertise.

In short, Automattic has gotten a black eye from a forced roll-out of a feature the larger community did not request, to solve a problem that only impacted Automattic, and all despite the vocal cries from the community to delay launch until the accessibility issues were addressed.

But Automattic can remedy this and come out looking pretty good.

A Way Out

Automattic can build a dedicated accessibility team. With that team, Automattic can honor Matt Mullenweg’s promise (quoted below) to set new accessibility best practices for the web overall.

[…] Automattic will be funding an accessibility study of WordPress, Gutenberg, and an evaluation of best practices across the web, to ensure WordPress is fully accessible and setting new standards for the web overall.

This team can then donate time to the theme and plug-in review process, either by doing reviews themselves or building a process to support the volunteers doing the work.

Training

In a comment Matt Mullenweg left on a post here, he asked what would qualify someone as an accessibility practitioner. Amanda Rush and I pointed out a bunch of resources in replies, ranging from the existing WordPress accessibility materials (put together by the WP Accessibility team) to free and paid training programs.

Automattic can purchase bulk licenses for paid online training and run its entire Gutenberg team and core team through the program. It can pay for on-site training for individual teams that are geographically close to one another. It is a model we have seen work elsewhere, such as how Target reacted to its own accessibility suits.

Automattic could even offer seats in the training (online, probably) to the WordPress volunteer team leads. It increases their skills and provides some benefit to donating all their time.

Hiring

Automattic is a billion three billion 7½ billion dollar company. Given what is pays developers, it can afford to hire a capable accessibility professional to help set standards. Add more money and it can hire all the way up to a Chief Accessibility Officer.

Automattic can, and should, seek accessibility consultants to get its new processes and teams off the ground. Having a dedicated person with a solid background in accessibility will be necessary to drive this effort on a day-to-day basis and carry the recommendations of consultants forward.

Testing

It is important to pay people to test, but especially to pay people with disabilities to perform testing as well. These are (likely) not hires, but is still about paying experts for their skills and insight.

Bringing people in to perform testing is critical for any project. After the accessibility work has been completed and accessibility testing has validated it, it is important to perform standard usability testing. That usability testing must include people with disabilities.

The process is not complex and recruiting participants can be easy when partnered with disability organizations. You can see an overview of a process from my talk at WordCamp London in 2018.

Process

Automattic needs to reaffirm its commitment to WCAG by baking it into the process. It has to be included in each step, starting with planning through deployment and every step between. Accessibility issues should be treated similarly to security issues — blocking issues that require resolution before something may proceed.

All of this has to be documented. Accessibility must be part of the definition of done. No longer should someone from the accessibility team need to justify how many users something may affect, nor how long it can delay a timeline.

Without getting in there as a consultant it is hard to offer more concrete recommendations, but these high level steps are common across organizations.

Benefits

Organizations who have considered a move away from WordPress, or who have already moved, would see a genuine effort on the part of Automattic to shore up the very deficiencies that drove them away. For those worried that WordPress has slid backward on accessibility, putting them, their organization, or their jobs at risk, this can be a signal that Automattic will not make the same mistake again.

Because Automattic would be expending both cash and effort to build the team, people would be more likely to believe that this is a promise Automattic, and by extension Matt Mullenweg and WordPress overall, are going to honor.

Automattic would also collect first-hand experience with what developers are building, how the accessibility of features can be unintentionally hobbled, and potentially come up with new and improved pattern libraries, processes, and best practices for the overall community to follow.

This can also mitigate legal risk — to some extent. For organizations on the platform who may face suits for inaccessible sites based on code they do not control, being able to demonstrate a genuine effort can delay or limit their exposure. It can make the risk-averse less worried about being on WordPress.

Feedback

This is a nascent idea. I do not have the institutional knowledge of WordPress nor Automattic to know how this may come together in practice. I do, however, have the experience of 20+ years of consulting with organizations at all scales to know that this can be done. All it takes is the commitment from leadership and guidance from those who have the experience.

That being said, I welcome feedback.

Update: 17 June 2019

A couple weeks ago Jeffrey Zeldman, long-time standards advocate who recently joined Automattic, posted Accessibility Standards: Defining What Success Means on the Automattic Design blog. I have been directly asked on a few occasions if this is what I was advocating for.

It is not.

That position piece is specifically for how Automattic’s internal design team works on projects for its own charity, celebrity, and influencer clients. This is not for the broader set of Automattic clients (yet?) and certainly not for the overall WordPress community — though I hope Automattic takes what it learns and percolates them up into the overall platform.

There is a Google Doc with Automattic’s first pass at Team 51 accessibility standards where your contributions are welcome (and requested).

In that Google Doc I saw no link to this post in there (which is fine and expected), but I have not added anything to the document. For a billion three billion 7½ billion dollar company, Automattic can and should bring in consultants, not continue to expect accessibility professionals to donate their time and skills. If anything, this ask from Automattic suggests Automattic is moving away from what I outline in my post above.

Update: 1 September 2020

Joe Dolson from the Make WordPress Accessible team gave an update at WPCampus Online on the ongoing work on the results from the Gutenberg accessibility audit (commissioned by WPCampus in late 2018 and delivered on 1 May 2019).

In 15 months the team has managed to work through two-thirds of the tickets, or 66 of them. While an impressive amount of work has been done by such a small team, let’s not forget how this is all clean-up from the two years of warnings prior to the Gutenberg launch that this would happen.

Automattic did not fund this audit, though it did donate some money, and Automattic is still relying on volunteer accessibility experts to do the work to make its platform legally viable for many of its customers. Remember, Automattic is a three billion dollar company.

A full transcript is available at the session page.

You can see open issues in Trac and on Github.

Update: September 25, 2020

As the W3C has embarked on a full web property rebuild, its vendor (Studio24) indirectly announced earlier this month that it had dropped WordPress from consideration as a CMS. WPTavern took issue with this yesterday, and Studio24 responded today, (politely) pointing the finger squarely at Gutenberg.

Part of WPTavern’s argument was that the selected platform (Craft CMS) is not open source software (OSS), though WordPress itself is not completely open source in practice (Slack versus IRC or MatterMost being the easiest example). More importantly, Gutenberg itself was not truly open source in process — Automattic drove it as a business decision reaction to the growth of Wix, Weebly, and SquareSpace.

Studio24 cited accessibility as the deciding factor. Automattic has already signaled accessibility is not a priority for it or its investment in Gutenberg. The community had to crowd-fund an audit, all while Gutenberg was pushed to final public release with dozens of known accessibility issues. The entire time, all the accessibility work was done by volunteers, not supported by Automattic’s $3 billion bulk in any meaningful way.

As Gutenberg works to replace some common plug-ins with its own features (think ACF), any code written today that uses the features of those plug-ins has a built-in expiration date. Even as Gutenberg’s scope continues to shift, the same confusion we saw over meta boxes will likely appear in other core WP features, warranting unanticipated code changes. This is an unnecessary and unknown future cost to the W3C.

By using a smaller platform (which has already made a public commitment to WCAG), the W3C has more leverage to force WCAG / ATAG compliance. It can do this in the contracts, where payments are tied to compliance. With WordPress, there is no way to do that. All accessibility work comes from the community; there is no way to enforce it.

Given the past behavior of Automattic (which predicts future actions) versus the published (and contractually obligated) commitments from Craft CMS, the W3C made the right call. It is an unfortunate black eye for OSS, and an unforced error on the part of Automattic that got us to this point, but here we very publicly are.

Related from me that informed this hot take:

• This post you are reading;
• First Reactions to Gutenberg (2017);
• Lessons from Gutenberg (2018).

Update: January 10, 2022

Joe Dolson calls out a cavalier tweet of mine in his post Don’t judge progress by the number of open issues.

He is right. Error density, changes in code over time, plus overall complexity changes, all factor into progress that raw numbers do not show. And as he notes, closing an issue does not necessarily mean fixing an issue.

My attempt at a joke was that Gutenberg was a more accessible product when it did not exist, as supported by my spurious math suggesting time flows backward. But it was also a shot at Automattic’s failure to support (in dollars and developers) the accessibility of the tool it forced through the process. Where the progress it makes is on the backs of OSS developers. And where Joe confirms in his post that it is still grimly inaccessible.

Gutenberg has been with us for 5 years (4½ since its announcement) and this (with my other posts) suggest Automattic’s 3 billion valuation dollars are still not being used to hire accessibility pros and assign them to the project and/or train the community on which it relies to support its product.

I have consistently judged progress by actions, and I still haven’t seen any from Automattic suggesting it has made any.

Update: February 28, 2024

Automattic, the 7½ billion dollar company behind WordPress.com and piles of plug-ins, is reportedly selling user / customer data to LLM companies to train their machine learning models.

I am willing to bet it will (continue to) not use this money to do anything I suggested above five years ago.

Update: April 17, 2024

WordPress Accessibility Day is asking for volunteers to provide translation review for LLM-translated conference presentations.

Automattic, the 7½ billion dollar company behind WordPress.com and piles of plug-ins, has not volunteered to simply fund it. Because Automattic continues to benefit from the free labor of the accessibility and localization community.

As far as I know, it has not done anything I suggested above five years ago.