Lessons from Gutenberg
The subsequent weeks and days proved to be wonderful insight into how a project can suffer when accessibility is not built in from the start. When subject matter experts are only included to mop up what few others consider to be bugs. When sprints and deadlines make no consideration of what are now remediation efforts.
You can read my Twitter thread and all the sources I link, but Andy Bell did a great job mining it for his post What Can Be Learned From The Gutenberg Accessibility Situation? over at Smashing Magazine.
Instead, I think there are lessons to be learned from Gutenberg that, thanks to its open nature, we can apply to other projects. Ideally, you want to make your next project the Anti-Gutenberg.
When Gutenberg was first formally announced at WordCamp Europe 2017, I wrote about what I heard from Matt on stage. The scope and objective of Gutenberg were not very clear.
Matt mostly tried to convey airy ideas of a modern interface, all while exposing his fear of Wix, SquareSpace, and Weebly. In other words, risks to Automattic’s business, but not WordPress itself.
With no clarity on how fundamental features of WordPress would be supported, no public release schedule, and no major community involvement to that point, it was clear that Gutenberg was generally un-scoped and those parts that might be scoped would suffer from scope creep.
Identify the output objective and the scope before committing any code, let alone any planning resources. Make sure stakeholders understand it. Publish it. Ensure a barrier to scope creep and a process to allow scope expansion. If accessibility is part of it (it should be) identify to what level and standard (eg. WCAG 2.1 AA).
Gutenberg has been framed as a community project, but Automattic has committed at least 40 employees. There are dozens of other volunteers, in many cases funded by their own employers. They are essentially free labor for Automattic’s agenda.
Gutenberg was never staffed for accessibility to be successful. We know that the accessibility team is small, over-taxed, and has little prior skill in React. That niche intersection of skills, React and deep accessibility knowledge, is hard to find and the Gutenberg project expects those people to volunteer. Accessibility scapegoating was (is) a very real concern.
Even the accessibility release lead Automattic provided for Gutenberg is not an accessibility practitioner. He has been thrust into a role overseeing an aspect with which he has little experience or training. At WordCamp US, Matt suggested that if you cannot get hired for a job doing the skill you want to contribute, then maybe you are not qualified to contribute. That message cuts both ways.
Training can get basic accessibility skills across a team. Deeper accessibility skills are tougher to find and typically come at a premium; pairing those with deeper technology stack skills compounds that. Given what it takes to get to that level, expect to pay good money for professionals, open source or not, and build them into the budget from day one.
Gutenberg is built on React. Much of the rest of WordPress is static HTML generated from PHP. The React developers overall had little or no accessibility experience. The accessibility team had little or no React experience. No effort appears to have been made to train either team to try to bridge that gap.
That meant that in many cases developers would be talking past each other. The accessibility team could identify what the HTML needed to look like to address an issue, but the React team might not have the needed control over the HTML output of React.
It is fair to expect the average developer to have little experience with screen readers or dictation software. But the developers did not even have the most fundamental training — testing keyboard accessibility during development.
Identify the skills you need for the project. If you can, build a team from your internal resources who have those skills. If you don’t have those skills on your team, train them. The fundamentals of accessibility can be easy to convey to a team, so do it.
Gutenberg was ultimately driven by engineering priorities. Release schedules, developer feedback, code commits, all moved at a timeline that was too aggressive for structured testing, let alone thoughtful development.
In many cases, new code was committed before requested accessibility feedback was provided. Anyone who wanted to review the accessibility was working on a constantly shifting codebase. In addition, breaking changes were constant. The accessibility team might fix an issue one day only to see it reappear a week or two later. With no process to prevent this, the accessibility team kept fighting the same fires, killing morale and leaving other parts of the project exposed.
Most fundamentally, accessibility was not incorporated from the start. Not in the project specification, not in the design phase, and not in the definition of done. Gutenberg was always going to be playing catch-up with accessibility, forcing it into a pain point of the project owners’ own creation.
Incorporate accessibility from the start. At planning, design, scoping, scheduling, testing, and every other step along the way accessibility must be incorporated. It saves time in the end and prevents a backlash against accessibility requirements and team members.
Gutenberg always had an artificial timeline. Each announcement of a new date was tied to an event, not to a discrete list of features or quality standards. With no clear definition of done, the target date became the only visible success metric and it was often unknown. It slipped multiple times, most recently November 19, then November 27, then no date, then abruptly December 6 (with just 4 days notice). The accessibility team did not know about the November 19 date until 6 weeks prior.
When you are targeting an artificial date, one that keeps shifting, that can undermine good development practices. Test cycles are reduced, decisions are made for expediency not user experience, and generally people are put under unnecessary pressure.
Note that repeated calls to delay the release until after an accessibility audit were dismissed. Even after conceding an audit might be useful, the community was told
the audit will not affect release timing and that it would be
more prudent to explore an audit on a less rushed timeline in the future.
Target dates are critical. Without them, projects may never end. However, target dates must be chosen based on scope, objective, and resources. They also must be allowed to slip when critical bugs are brought to light (such as the legal risk of an inaccessible product). Otherwise they become pain points that can justify poor decisions.
Messaging was disjointed and inconsistent. Sometimes news came on the Make-dot site, sometimes in comments on other’s posts, sometimes in Matt’s posts on his own blog. Finding a clear plan with updates became tricky. Expecting WordPress community members to follow every passing tweet, GitHub comment, or Slack missive is a very high bar.
As Matt was making assertions that he believe Gutenberg was more accessible, he would never answer requests for evidence. When Automattic committed to an accessibility audit via GitHub, it later dropped it, then Matt suggested the audit was never off via a (petty) tweet (now deleted), then announced the audit on his own site.
All the while, Matt and others from Automattic stressed that Gutenberg was a community project. They constantly used the word
we, even though it was clear
we had a shifting meaning. This was enough of a question that Matt was asked at WordCamp US to clarify who
Somebody needs to be the sole communicator, and that communication should come via, or funnel to, a single platform. Avoid words like we when the bulk of the team, community, public, etc. feel their voices have not been heard. Do not dismiss genuine concerns from the community and/or experts, and certainly do not threaten them.
Arguably, the biggest problem with Gutenberg’s accessibility is not code. It is lack of leadership. The tone-deaf response to real concerns compounds it. Much of the messaging confusion came from the top, and much of the public frustration with the project came from Matt’s public behavior.
With Matt’s role in the tech industry on the whole (not just helming a
billion-plus dollar company), and the power dynamic that brings, he spent too much time punching down (he deleted this tweet), making false assertions, and making community promises and personal commitments he has so far failed to keep. I am not the only one who will believe his commitment to fund WPCampus’s accessibility audit only after the payment has cleared, and I hope this motivates him to finally keep one of his commitments.
This is not how a community nor project leader behaves. This is how someone behaves who cares more about an artificial deadline driven by fear of competitors’ impact to the bottom line. With the exception of the people who need something from him (such as a paycheck), he has burned a lot of goodwill from the very people he needs to move his agenda forward.
Addendum: December 14, 2018
My 404 handler notified me that Matt deleted the tweet I linked. The tweet where he effectively tried to cost a women in tech her job for a tweet that did not mention him nor was inflammatory. He did no such thing to any men in tech for far more inflammatory tweets. He also failed to publicly apologize. I don’t believe people with that kind of influence should get away with erasing history. Or be in charge of a project with such a large influence over the web.
Whomever is in charge needs to check his or her ego and listen to the team, as well as the customers and users. That person must also honor any commitments he or she has made, as doing otherwise will damage the credibility of not just leadership, but the project as a whole.
I may have spent more time cutting this post after writing it in bits and parts over the last month. There are just so many examples of how this project’s failure to address accessibility has damaged the image of the flagship feature of WordPress 5.0 that had I included them then my original Twitter thread would have been light reading by comparison.
This post paints broad strokes for a reason. Lots of people gave their time and effort and their work should not be diminished. A broken project, however, can make everyone resent it and the people behind it.
I hope that Gutenberg will be successful, but it and other projects cannot be when they are mismanaged at the most basic level.
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.
Fantastic post and I agree 100%, both from watching this unfold and from experiences on other projects.
The accessibility team might fix an issue one day only to see it reappear a week or two later. With no process to prevent this, the accessibility team kept fighting the same fires, killing morale and leaving other parts of the project exposed.
What processes have you come across to prevent this? For frontend projects which are under development, where automated testing feels (is?) unfeasible, are there processes to prevent problems re-appearing? I’ve seen this even with simple responsive websites, where a CSS fix for one viewport has consequences in another. It’s one of those brittle parts I would love to improve in my practice.
A good process adapts to the team and organization using it. I have seen assorted approaches. Organizations that follow a test-driven development methodology tend to do reasonably well. Integrating a tool like Tenon to perform automated testing and prevent code commits for the violations that can be caught is an approach.
For those cases where automated testing is not a fit, developers need a process that helps them understand the starting state and the effects their changes have. Documenting the code can help that as well. But ultimately, testing is the key.
Development needs to honor the time needed to run tests and read the results. Generally the Gutenberg devs struggled with this for accessibility issues.
I would love to hear how others have dealt with it in their organizations.
So I know for next time, what “experience and training” do you feel would make for someone to be qualified as an “accessibility practitioner”? Something objective and publicly recognized would be great.
I want to qualify, becoming an accessibility practitioner is different than getting accessibility training. The former is far more in depth. International Association of Accessibility Professionals (IAAP) offers courses and certification programs to help someone on that path, and while IAAP’s material is not held in the highest regard by those who have been in the industry for a while, it can be a good first step for the uninitiated. I am not a member.
For those who want to get accessibility training without moving into a career in accessibility, there are free courses available, such as the two week program at Udacity sponsored by Google. It is part of the overallnanodegreefull-stack developer program.
There are many other courses (free and not) on accessibility on other platforms, including two from people already well-regarded in the WordPress community (Joe Dolson and Morton Rand-Hendriksen).
Lynda.com, Udemy, Udacity, [insert name of online learning platform here] all have accessibility courses targeted at different technology stacks and skill levels. From experience, you can even approach these vendors about purchasing a group license to let a bunch of people take the training. For example, buy a 40 seat license at a discount to get each Automattic member of the Gutenberg team trained, or buy a 50 seat license and let 10 community contributors take it as well.
The thing I have intentionally excluded is paying for someone to come in and deliver an in-person training session. I excluded that because I do that, and I don’t want to promote my services until I know there is a genuine interest from the stakeholders and team members.
From the WordPress Accessibility Handbook page on training and resources: A pretty extensive list of accessibility courses and videos Mozilla’s web accessibility documentation, also pretty extensive, resources, including tutorials, from WebAIM, resources from the Paciello Group, and finally, for on-the-spot questions, the WebAIM mailing list. I’ve grabbed these resources and pointed them out just in case Matt’s comment/question is a sincere one, although I suspect that there is a distinct possibility of trolling going on here.
Matt, not sure what you mean by “objective and publicly recognized”. Once you get past the basics of accessibility, whole swaths of it are, in my experience, subjective. That subjectivity is determined by: (1) the problem, (at a high-level view and broken down into its various sub-problems, with detail) you are attempting to solve; (2) the needs of people with disabilities; (3) the advice of non-disabled practitioners, (who ensure that all disability groups are served to the extent possible given the problem). As far as “publicly recognizable” is concerned, I think it’s fair to ask: Who is the public? What counts as recognizable?
Matt’s response smells very much like the unpleasant twitter response at Marcy Sutton.
Upside: The behavior is consistent
Downside: The behavior is consistent