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.
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.