Discussion surrounding Gutenberg’s independent accessibility audit is heating up. Two weeks ago, Matthew MacPherson, who was named WordPress 5.0’s new accessibility lead, proposed the audit and agreed to it being performed by an independent third party. The audit had gained strong support among accessibility contributors and others following the ticket.
After soliciting detailed proposals from four companies, MacPherson has since rescinded the offer to coordinate the audit at this time and it seems he was unaware that he didn’t have the authority to authorize it in the first place.
“For at least the time being, Automattic has decided to forgo conducting an Accessibility audit on Gutenberg,” MacPherson said. He cited the following reasons:
- “an audit will not be actionable given our release timeline, because…
- the audit will not affect release timing, so…
- it would be more prudent to explore an audit on a less rushed timeline in the future”
MacPherson apologized for “getting hopes up and then failing the community” on this particular issue. He is supportive of getting an audit but it is not a priority to complete before Gutenberg’s merge proposal.
“I’m hopeful we’ll explore an audit going forward, but unfortunately it will not happen before the merge proposal and thus I’m closing this issue as a won’t fix,” MacPherson said. “I would still like to blog about the state of Gutenberg accessibility, both the good and the bad. We’re making some improvements to keyboard navigation, color contrast, focus behavior, and date/color-pickers just this week.”
Those following the ticket were disappointed in the decision and several heated replies have been hidden and/or moderated. The issue has since been locked and unlocked several times since the announcement that Automattic has decided to forgo the audit.
“Literally every person with disabilities who has tested Gutenberg, both recently and at the outset, has flagged blocking issues as to why it’s not accessible,” Accessibility team member Amanda Rush said. “And user testing is just as important to accessibility as is WCAG 2.0 level AA compliance.”
Because MacPherson said the decision came from Automattic, dissidents on the other side of the issue are saying that the company is acting in its own interests, as the decision was delivered without much explanation beyond an audit not fitting into Gutenberg’s timeline.
Gutenberg appears to be a commercially-driven add-on primarily intended for a8c’s benefit and should probably be treated as such by the community wherever that isn’t already true. pic.twitter.com/c3yFImB5XL
— Doug is not, in fact, a potato (@zamoose) October 16, 2018
So disappointed in @automattic’s decision to forego an independent accessibility audit for Gutenberg. Shipping with known issues is the wrong way to go. Users with disabilities are more important than that! https://t.co/Z4diHmv4GX
— Marcy Sutton Todd (@marcysutton) October 16, 2018
“The idea of accessibility being punted to meet a release deadline is what people have been worried about for over a year, and those concerns have not been alleviated,” Morten Rand-Hendriksen said during a recent Accessibility team meeting on Slack before the audit was post-poned. “A clear message about what would happen should the audit come back with substantial issues and recommendations would greatly improve communication and take some of the tension out of the conversation in my opinion.”
In response to one contributor asking how the audit might affect Gutenberg’s timeline, MacPherson said he doesn’t have veto power over the release, nor does he have the data to make that assessment.
“I’m still not convinced there are sufficient Accessibility issues that prevent a release,” MacPherson said. “If the second point changes, I’ll relay that info. I plan to be an advocate, but I don’t set the timelines and I also don’t have solid data around accessibility. That’s the point of the audit: so we can speak from a place of hard data.”
An independent accessibility audit would have revealed whether the team’s current perceptions of Gutenberg’s lack of accessibility are accurate or inflated. It would also give the team’s new leadership the data he needs in order to make the most accurate recommendations regarding its readiness for the world. Kevin Hoffman advocated for pushing on with the audit regardless, in case WordPress 5.0 comes on a later timeline.
“The January 22, 2019 date would allow more than three months between today and the release of 5.0 to complete an audit and take action,” Hoffman said. “The reasons above suggest that we cannot get an audit completed and significantly improve accessibility in three months time. If true, that is all the more reason to start the process now and respond to the audit by fixing as many issues as we can before 5.0 releases.
“The idea that the timeline will become less rushed after 5.0 (when it’s in the hands of real-world users who need it most) makes no sense at all.”
As a blind #WordPress user & sometime dev I really appreciate your work & it is a real tragedy that the leaders of WordPress & this project didn't build in #a11y from the very beginning – Any good team knows it is much harder to fix in hindsight
— Dale Reardon (@DaleReardon) October 9, 2018
Absolutely this. Like most prior #WordPress admin functionality, #Gutenberg has been designed and built with hardly any thought for #a11y. And the WP A11y Team have been left the job of trying to help retrofit it. This always ends badly – in burn out, and half-baked solutions. https://t.co/UKMR442gM5
— CoolfieldsConsulting (@coolfields) October 10, 2018
While Twitter’s court of public opinion cannot answer the question of whether or not Gutenberg is accessible, an independent audit would give contributors a good shot at resolving the most critical issues.
“I really like the idea of a professional audit, though I don’t recall us ever doing one of these in WordPress, certainly not a condition for a release,” Gutenberg merge lead Gary Pendergast said. “I’d love to see something like it happen at some point. WordPress has always tried to get most of the way there on accessibility by sticking to common patterns and semantics, with the difference covered by key efforts of volunteers everyone on the Accessibility team doing testing and filing actionable bug reports. Gutenberg’s move to being an entirely JavaScript-based application has made it harder to apply those patterns, but we can work together to establish new patterns, a new baseline.”
Although there is no precedent for it, in this instance where Automattic’s perception of the editor’s accessibility differs wildly from that of the community, an outside audit might mitigate some of the conflict surrounding the issue.
Pendergast said that despite best intentions and prioritizing accessibility, there is a possibility the Gutenberg team may not be able to deliver an “acceptable UX for assistive technology users by the time 5.0 is released.”
“I’m sorry,” Pendergast said. “Despite the best intentions of everyone on the Gutenberg team, we haven’t done enough. I can honestly say that accessibility has always been a priority, but it hasn’t been a high enough priority, and we’ve done a poor job of communicating where accessibility has been improved. I mentioned some of those improvements in my earlier comment, but those improvements are of no benefit if we haven’t hit the baseline accessible experience.”
The challenge of building in accessibility at the design stage, instead of retrofitting it after the fact, is one that WordPress is still struggling to get right in the Gutenberg era. Accessibility experts with React skills are few and far between, so it’s not easy to get fixes for all the issues testers are finding.
“In some meetings we’ve discussed how to make accessibility integrated in the design process (design in its broader sense) since the beginning,” Accessibility specialist Andrea Fercia said during the team’s most recent meeting on Slack. “This is certainly an area were our communication and knowledge sharing should improve.”
How about we don’t have Gary Pendergast an Automattician(!) managing the core merge of an Automattic-developed feature project into a wp.org release led by the CEO of Automattic? The conflicts of interest in this a release process are amazing me.
Release Lead: Matt Mullenweg, Automattic CEO
Core Developer managing the merge: Gary Pendergast, Automattic
5.0 Release Manager: Josepha Haden, Automattic
Twenty Nineteen Designer: Allan Cole, Automattic
Gutenberg Leads:
Accessibility: Matthew MacPherson, Automattic
Design: Tammie Lister, Automattic
Development: Matias Ventura, Automattic
Phase 2 Development: Alexis Lloyd and Riad Benguella, Automattic
These are all good people, but are they willing to put principle ahead of angering their employer? The accessibility lead said he can’t affect the timeline. Why not??
In all releases before 5.0 new features went through process with core teams to make sure they followed core standards. 5.0? Automattic decides. Why??