WordPress’ accessibility team has published a statement on the level of overall accessibility of Gutenberg. The team, largely a group of unpaid volunteers, collaborated on a detailed assessment that publicly challenges Gutenberg’s readiness for core in a way that no other WordPress team has done through official channels to date. After a week of testing the most recent version of the plugin, the team concluded that they cannot recommend Gutenberg to be used by anyone who relies on assistive technology.
The Accessibility team – like any team in WordPress – has no specific authority over the project. Because we’re a small team of volunteers, we’ve been pragmatic in how we apply the guidelines. We have made tradeoffs in prioritization. Gutenberg is a place where we feel it is necessary to draw a line. The ability to author, edit, and publish posts is the primary purpose of WordPress.
Accessibility team rep Joe Dolson, speaking on behalf of the team, cited cognitive load and complexity, inconsistent user interface behavior, heavy reliance on keyboard shortcuts, and difficulties with keyboard navigation through blocks, among other concerns about Gutenberg. He outlined an example of the keyboard sequence required to do something as simple as change the font size in a paragraph block. It currently requires 34 separate keyboard stops, and even more if the tester doesn’t have prior knowledge of how to navigate Gutenberg.
“Because the complexity of interaction with Gutenberg is an order of magnitude greater than in the classic editor, we believe that Gutenberg is less accessible than the existing classic editor, though it offers many great features that are not available in the current editor,” Dolson said.
This assessment echoes many of the common themes found in Gutenberg’s reviews on WordPress.org, even among the most recent reviews of the latest version. Ratings are currently hovering at 2.3 out of 5 stars. Users have repeatedly said the interface is “far too heavily reliant on hover based functionality.” Even those without accessibility needs find it confusing, unintuitive, and difficult to navigate content. Some testers find it nearly impossible to do what they want to do with it.
The positive reviews recognize the software as a work in progress and testers seem more aware of the overall vision for the plugin. They are excited about some of the more advanced features that blocks offer, but many positive reviewers urge WordPress to give it more time before making it the default editor.
The accessibility team is convinced that the main accessibility issues in Gutenberg stem from design issues.
“Gutenberg is the way of the future in WordPress, but the direction it has taken so far has been worrying,” Dolson said. “We do not want to miss the opportunity to build a modern and inclusive application for WordPress, but in order to achieve that goal, accessibility needs to incorporated in all design processes in the project.
“These problems are solvable. Retrofitting accessibility is not an effective process. It is costly in terms of time and resources.”
In a recent post titled Iterating on Merge Proposals, Gary Pendergast, who is leading the merge of Gutenberg into core, acknowledged that they could have asked for the accessibility team’s help much earlier in the process.
“The Accessibility team should’ve been consulted more closely, much earlier in the process, and that’s a mistake I expect to see rectified as the Gutenberg project moves into its next phase after WordPress 5.0,” Pendergast said. “While Gutenberg has always aimed to prioritize accessibility, both providing tools to make the block editor more accessible, as well as encouraging authors to publish accessible content, there are still areas where we can improve.”
At this time there has been no official response to the accessibility team’s assessment. It does not look like it will meaningfully impact the release date, as Beta 2 went out last night and RC 1 is planned for release today. If the core dev chats are any indication, contributors involved in 5.0 seem to be on board with the ambitious timeline for its release.
In a post titled “Accessibility in Gutenberg is not a one-more feature,” core developer Drew Jaynes urges the project’s leadership and contributors not to compromise core accessibility standards for the sake of an expedited timeline.
“Please let’s not make the ‘new standard’ be that we’re willing to ship technically accessible but perhaps not entirely usable-for-all features; let’s not define it as one that sacrifices standards core to the WordPress experience in the name of perceived expediency; let’s not define it as the new default authoring experience for all users when not all users can use it well,” Jaynes said.
WordPress 5.0 release lead Matt Mullenweg has frequently said the release will ship when it’s ready. He contends that the interface has been continually modified for accessibility needs throughout the process of developing Gutenberg.
Modifying the interface to accomodate a11y is the compromise, it has been continuous throughout the process. I don't know how to achieve the imaginary bar you're setting up.
— Matt Mullenweg (@photomatt) October 26, 2018
Matthew MacPherson, Gutenberg’s accessibility lead, was not immediately available for comment on the team’s assessment. Ultimately, the decision to delay the release will fall to Mullenweg and his leadership team. The accessibility team, however, will not lend its endorsement of Gutenberg at this time:
The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.
Gutenberg is now 20 days away from landing in WordPress 5.0, but this does not leave enough time to solve the design and architectural issues the accessibility team has identified. They have proposed a notice on the 5.0 release to inform administrators of Gutenberg’s inadequacy for users of assistive technology, with a prompt to install the Classic Editor plugin. Many people with accessibility needs depend on the WordPress editor in order to do their work and will need to stick with the old interface. The proposal has been closed with a note indicating that 5.0 will point users to the Classic Editor plugin if they need it.
The mistake of not having consulted accessibility experts in the design phase cannot be easily rectified at this point, but the Classic Editor is still available for those who need to preserve their same workflow. The conflict lies in whether WordPress should ship a new editor that those with accessibility needs cannot immediately use. It is a somewhat painful and frustrating outcome for those users when the entire ecosystem is rapidly moving towards Gutenberg as the standard.
Either the accessibility and usability issues the team identified are not as bad as they purport or this document is a last-minute clarion call that could prevent WordPress from shipping an editor that excludes users who rely on assistive technology. Due to the gravity of their claims, the accessibility team’s statement on Gutenberg demands an official response.
The post was one of the more rationale and reasoned looks at everything, and I really appreciate Joe and the team’s work in putting it together. It’s a starting point for prioritizing the extensive accessibility work that has gone into improving WP’s core editor already, but a key thing we have to fix is the team working in a less adversarial way with all the other contributors to WordPress — for example collaborating on posts like this, not tossing them over the transom. Some things like “icon-only controls,” which are in every modern web app, are going to require further discussion. What’s also getting lost is many things have already vastly improved over our old TinyMCE experience, including galleries, embeds, color picking, adjusting fonts (or design elements at all), and keyboard shortcuts. I’d also like to expand the conversation to cover widgets, nav menus, CodeMirror template editing, and other aspects I consider key to the WP experience beyond just publishing — our accessibility tent should include those and doesn’t currently.
WP’s super transparent and open development style means that these bumps in teams working together happens in public and that can sometimes cause more polarization as people pick sides or inflame things on Twitter, but the reality is that we are all working toward the same goals. Someone told me they were abandoning WordPress and switching to Squarespace because of the accessibility stuff… without realizing Squarespace’s block editor is way less accessible than Gutenberg, besides the fact that it’s proprietary and commercial.
We all want open source to win. We all want publishing online to be accessible to as many people as possible. Communication is key and I’m glad everyone is talking to each other more, and we’ve begun to move away from the Twitter-style attacks (“fundamental ignorance and disregard for accessibility and amateurish approach to product management”) to practical next steps and improvements.