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.
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.
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.
Automattic is a
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.
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.
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.
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.
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 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.
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:
Yes Adrian, this is exactly what should happen. Thanks for collecting the ideas together in a clear and well-argued way.
This is a well-put post, and I very much hope that your ideas are adopted by Automattic. Content editing is just the tip of the iceberg with regard too accessibility, and specifically some of the accessibility lawsuits/demand letters/precautionary steps I’m seeing. ECommerce in the WordPress space, (third-party extensions for WooCommerce, for example), as well as page building, (Visual Composer for example), are creating problems for users in the business space they never intended to take on. This is only going to worsen.
Excellent post. I certainly hope WordPress listens!
Though I like the current WordPress ecosystem. Your model looks promising for me. WP Community should think on it.
Thanks for sharing you thoughts.
This is a really solid plan.
If WordPress adopts a culture of accessibility, with the skills and knowledge to match, it can only be a win-win for the project and the users.