The Gutenberg team has officially responded to recent concerns about the new editor’s accessibility. Matias Ventura, the project’s technical lead, published a post with examples of the accessibility efforts the team has made, many which may not be easy to discover. These include features such as keyboard shortcuts, slash command and insertion, high-contrast mode, and mechanisms for navigating regions and blocks with the keyboard.

Ventura highlighted the audible messages feature that works with screen readers and posted a demo of the fully automated end-to-end testing. It allows contributors to test a sequence of operations with the keyboard (without mouse controls). He also identified several fixes landing in the next releases, including accessibility improvements to the date and color picker features, block navigation, and better focus management.

“A large amount of work and effort has gone in building mechanisms necessary to make the editor accessible for a wide user base,” Ventura said. “For example, it is entirely possible right now to recreate the ‘demo post’ that comes with the Gutenberg plugin using the keyboard. In many ways, these tools are better and more sophisticated than what we offer in the current editor.”

Although 270 accessibility-specific tickets have been closed to date, Ventura acknowledged there are still more than 90 remaining. “The goal is to make this experience as seamless as possible for all users,” he said.

Early reactions to the post do not dispute that accessibility work has been done but concerns about Gutenberg’s overall complexity remain. Fixing this may not be as simple as targeting isolated interactions in the editor.

“We need to continue to develop close feedback loops with different users interacting through their preferred tools to make sure what we build is relevant to their experiences,” Ventura said. Throughout the process of building and testing Gutenberg, contributors have referenced “short feedback loops,” an agile process term that seems to make its way into these conversations.

However, the frequent built-in checkpoints don’t seem to have served accessibility needs well, as the accessibility team in convinced that having their input much earlier in the design process would have made a bigger difference further downstream.

“We’ve been begging for React development assistance focused on accessibility since the beginning,” Accessibility specialist Joe Dolson said in a post addressing what he perceives to be common myths about Gutenberg’s accessibility. “None of us were already primarily JavaScript-focused, let alone React-focused, and with limited time (spread across Gutenberg, the rest of WordPress, all of the WordPress sites themselves, and theme concerns), managing to keep up with the breakneck pace of development was never feasible.”

WordPress core contributor John James Jacoby commented on Ventura’s post, calling attention to the complexity of the interface for all users, including those with and without accessibility needs.

“My concern is that many of the above things do not really improve accessibility in the broader sense,” Jacoby said. “Instead, they make a complex user interface more complicated by littering the landscape with hidden keyboard shortcuts that are likely to be undiscoverable by regular-bodied folks, let alone folks who lack dexterity in their hands or fingers or eyes to find/understand/navigate/enjoy them.

“These are users who demand a semantically simpler application to get their jobs done. Though they’re used to quickly navigating the useless mixed-up garbage-markup soup that comes from web development as a whole, it doesn’t help to add extra ‘accessibility-centric’ approaches – we should be making the existing approaches accessible first, and adding new approaches after.”

Dolson echoes that sentiment in his recent post. “Where Gutenberg falls down is on the overall use of the system,” he said. “Even though most individual interactions are handled effectively, the overall complexity of the system creates an enormous barrier to users if they are keyboard dependent or using a screen reader.”

The community has advocated for a myriad of different needs and wishes during the course of Gutenberg’s development, but any interface created for the millions of people that WordPress aims to serve will inevitably have to deliver some compromises. Matt Mullenweg answered the feedback regarding complexity from his perspective as the project lead:

“We think that the current interface could be a ton more streamlined, but we’ve compromised a lot of the alternative approaches we’ve wanted to take based on accessibility feedback and trying to have a single interface that serves all types of users,” Mullenweg said. “If we branched, it would be a different discussion and possibly serve multiple audiences better. There’s a lot of FUD though, ie, that’s going to be illegal in EU.”

Ventura’s post is tightly focused on Gutenberg’s existing accessibility features and makes no mention of the audit that would have measured if it meets WordPress’ own stated accessibility standards. These standards require that all new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA. Without an examination of how the product meets these standards, much of the the discussion revolves around subjective opinions about complexity. It’s difficult to quantify issues like cognitive overload.

“It is entirely possible that Gutenberg will come within a hair of passing WCAG (Web Content Accessibility Guidelines) 2.0 at level AA at release, but still be inaccessible,” Dolson said. “This is because the micro-interactions are being managed well but the macro-interactions are not. This is a flaw with using WCAG 2.0 as a standard; it does not handle address large scale issues effectively. The cognitive load inherent in the current navigation requirements for assistive technology is overwhelming, and that is an accessibility issue – just not one effectively reflected in our current standards requirements.”

One of the myths Dolson’s post dispelled is that the Gutenberg team doesn’t care about accessibility. Ventura’s post calls attention what he believes to be “a significant volume of accessibility-specific tools and functionalities” in Gutenberg that surpass those of the Classic Editor. The team has worked hard to address accessibility concerns but needs better communication across teams in order to continue serving the wider community of WordPress users with accessibility needs.

“There have been a lot of issues on the way that could have been avoided if a React developer had been available to assist with significant dedicated time earlier than 6 weeks before the proposed release; but those were issues coming from ignorance, not a lack of compassion,” Dolson said.

“I don’t know what Gutenberg will be at release. But the accessibility team and the Gutenberg team are working hard to try and reach the best solutions we can.”