Gutenberg Accessibility Audit Postponed Indefinitely
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
— Given enough eyeballs, all Dougs are shallow (@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 (@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.”
26 Comments
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??
Report
I see what you’re saying but why is this a bad thing? Can you point to instances or situations where having these people in these positions have negatively impacted the project? Automattic is not deciding, Matt Mullenweg is as the project leader.
Report
So Automattic is deciding. Matt is Automattic just as much or more that he’s “the project leader”.
There isnt the advice and consent there was before. There is decisions that come down from on high and those are the decisions that are chosen. Users are ignored. Accessibility team is ignored. Why??
Why does Rian have to resign? Why do core developers have their concerns dismissed?? Arent they the ones who approve merges? Where are the checks on this power handed to Gutenberg by Matt Mullenweg, CEO of Automattic??
Report
It’s a bad thing because WordPress Core is (ostensibly) a non-profit and consensus-driven project built by the collective contributions of the open-source community and not Automattic’s private project.
Stacking the Gutenberg leadership with paid Automattic employees and ignoring the community’s feedback so blatantly sends the message that Gutenberg is being built for Automattic, 15 years of community and WordPress ideals be danged.
I actually think Gutenberg is an excellent and much needed addition to the WP ecosystem, but the way it is being forced into Core without achieving any kind of consensus and common ground with the community and without adhering to the inclusive and cooperative ideals that made WP what it is, is deeply concerning.
I really wish Automattic had built this internally and released it as an ‘official’ plugin like Jetpack. I bet the reception and adoption would have been totally different.
I believe there is still time to make this work. We just need to return to what made WP great to begin with: community and inclusiveness.
Report
@jessica h: sorry, but I think the chance to change things from within WP is long gone by.
I’ve been watching this train wreck in motion for the last 4 – 5 years, and Gutenberg is just the last straw. Now its either swallowing what Automattic decides = continuing riding a dead horse, or put your tabs on a still living one, eg. one of the forks (ClassicPress and CalmPress).
cu, w0lf.
Report
Jeff Chandler is also an employee of Automattic as Matt Mullnweg, CEO of Automattic owns the WP Tavern website.
Report
No, I’m an employee of Audrey Human Capital LLC, a separate company owned by Matt Mullenweg who also owns WP Tavern
Report
I feel sorry for Matthew MacPherson that he’s been given the job of acting as a mudguard for Matt’s decision to throw people with disabilities under the bus in the quest for greater market-share.
To become the new accessibility lead, publicly call for an audit, then have the man at the top pull the rug out from beneath you – yikes.
The development process for Gutenberg has been much more like one for a private company than a community-driven open source project.
Let’s be honest – most of the important decisions are made in private. Slack channels, Github issues, and ‘Make’ blogs give it the appearance of being more open than it really is.
Sometimes it seems as though the community is seen as a hindrance by those who really control WordPress.
I’m pro-Gutenberg, I hope Phase 2 is handled better than this.
Report
Agree with this 100%. It’s hard to argue that Gutenberg is anything other than a Automattic run project. The people, the methodology, the governance(!), the lack of clear roadmap or objectives, the technologies, the arbitrary deadlines – the list goes on.
Making things accessible is a fundamental part of doing our job properly as developers.
The a11y team have done brilliant work at making it possible for more people to use WordPress, and the fact that the standards that have been put in place are being treated as optional is just not right. It is an embarrassment watching people call the WordPress project out on this.
If Matt wants to ignore accessibility at Automattic, good luck to him – but let’s not make it harder for people to use open source software that powers 30% of the web (think of it as market share if that helps, Matt).
Report
Just follow the money, after 5.0 hits the road…
Report
I do think that accessability is a very important concern for any project and I think that ideally it would be ready prior to Gberg launch.
Having said that I think the primary reason the team is focused on an expedited launch is because until it becomes official Gberg will always be a ‘feature plugin’ and the majority of the eco system will not prioritizes it.
For example a handful of the plugins we commonly use on our client sites are not compatible with Gutenberg. We have lodged support requests with the plugin developers and the response is more or less: “We plan to look at this once Gutenberg becomes official”
Report
It’s a bit more serious than that. There’s no “think” or “very important” or “ideally”. Even human issues aside, In some countries there are explicit legal requirements. Accessibility isn’t an add on or a nice to have.
Report
Gutenberg has been like watching a car crash in slow motion. There have been so many opportunities to listen to the community and make an change in direction, and yet here we are – 31 days to go until the official launch date of WordPress 5.0 and there are still 1,200 outstanding issues on the Gutenberg repository.
Report
Issue/ticket count is not a great way to judge a project.
WordPress has over 6000 open tickets on Trac.
Report
I’m not against Gutenberg (at all), but if it’s not accessible for everyone, they should postpone a release.
Just having the “Classic Editor” as a fallback (plugin) is wrong. Accessibility should be part of WP:
Report
Like someone said in another post, WordPress has sadly shifted from open-source project with a hosted platform to a hosted platform with an open-source option, and now everything is planned according to the wishes and needs of the hosted platform.
Report
More and more it looks like it is the case… So, hard forks will be justified, accordingly.
Report
It would be in everyone’s best interests if WordPress were accurately described. It is a product created and distributed by Automattic under an open source license that allows individuals and organizations to freely use the software. If you stop looking at it or calling it a community driven project (as is proving to be the case), the sting of these decisions goes down some.
Report
I’ve had this niggling thought for a long time. An awkward thought “what is Gutenberg aiming to solve?”. What are the goals, how do we know we have succeeded?
The official WordPress statement : “The goal is to create a new post and page editing experience that makes it easy for anyone to create rich post layouts”.
As a badly educated Dev I often ask about goals to find the most elegant solution – because it saves me effort, time and money.
The core of WP to me is the engine which sits processing code on the server, functions we can call which can be requested by any interface we dream up. The API, and WP CLI will translate any trigger we send from any interface: a visual interface trigger, a haptic trigger, a vocal trigger, … all of these and more.
The old WP editor was a bad interface for the expanding core functionality and better interfaces DID need to be created – and the API and CLI are now powerful enough to do the grunt work of interfacing with the outside world. I’m sure we’ve all made a headless WP and a mobile phone app test. That seemed to be the future direction.
So – the official WordPress goal : “to create a new post and page editing experience that makes it easy for anyone to create rich post layouts”.
That doesn’t say “make a drag and drop page builder” or “make a GUI page builder”. It says the goal is to enable anyone to make rich post layouts”.
What would be the most cost effective way to achieve that? A better rich post editor for everyone. Personally, for my own business I’d look to see if there’s an existing visual editor using my API that I could license. No need to re-invent the wheel if somebody has made a wheel for my API.
Then I’d look to build other interfaces suitable for visually impaired, movement impaired. All my work would be on my API, and I’d capitalise on the community to create interfaces to that.
Instead … and I’m sure I’m the idiot here … the team seem to have focused on building a visual drag and drop block page layout editor which is less good than the competitors. A redundant and costly effort.
I can’t see how this satisfies the stated kick-off goal elegantly and with lowest cost for highest value return.
To my mind this project and the goal satisfaction has been led astray by a current WebDev interests in SPAs, modern UI JS libs and trends in JS. I’m sure this looks great ona CV but the project management is … lacking.
It seems technology led rather than goal led.
Of course, I’m probably missing something important here. I don’t come from a technical CompSci background. I’m more of a “solutions” kind of person.
Report
A independent a11y review would have been very nice. Being the tech lead for the Norwegian Government WordPress sites, I’ll have to find funding to do a our own review (we’re using https://www.funka.com/en/) before I can introduce Gutenberg to our users. Not sure I’ll be able get the funding in 2019.
Report
I’m thinking of the number of universities in the US using WP multisite for faculty and staff (like University of California, Irvine), and once this pushes out, unless the university makes the Classic Press plugin as an available plugin, the universities will no longer be in compliance with ADA. I’m not talking about the front end. I’m talking about the content editor. Just when I think I can’t be shocked any more, Automattic pulls this. And the buck stops at Matt’s desk.
Report
Great management. The audit isn’t wanted because Matt doesn’t want the results it would yield publicized.
Report
I just want to add that Gutenberg is a 2017-2018 project. WordPress editor is more than a decade old. It’s not fair nor logical to compare both, as the knowledge and use for people with disabilities has shifted a lot in the last decade.
The WordPress project has to focus on its mission. If it can’t be accomplished we’re failing.
Report
And “The Wolf of WordPress” series continues.
I guess we should have paid even more attention to what Automattic was doing with Jetpack… But who knew they would go this far this quickly?
It’s one thing to downplay criticism from a few developers, but it’s a completely different level of arrogance to sideline millions of people just to meet a corporate deadline.
I guess an Automattic + Alphabet is as natural and obvious as one can be :\
Report
So, I have a proposal out to a public institution. I need to check but if they require accessibility support then 5.0 is a non-starter.That means 1) Launching and staying on the 4.9 branch until this is fixed or 2) using something else. I’m inclined to simply use something else.
Report
I have a proposal out to a large public institution too, using WP multisite. My client is one of the professors. My sister is a Lecturer SOE there. I’ve been able to ascertain the university will NOT upgrade to 5.0 until they have fully tested it and can confirm that 5.0 is accessible to faculty and staff on the editor side, too, and that it doesn’t have any other bugs.
That means that any new updates that would also address security issues will not be made, because Automattic has deprioritized accessibility federally required for public institutions.
Report
Comments are closed.