Gutenberg Team Addresses Accessibility Concerns, Highlights Tools and Features...

wordpress
gutenberg
wcag
Tags: #<Tag:0x00007f21ad8e8bd8> #<Tag:0x00007f21ad8e8a98> #<Tag:0x00007f21ad8e8958>

#1

Remember Gutenberg Accessibility Audit Postponed Indefinitely?

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.

The article goes on:

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.

Okay, so there’s that, but here’s a remark:

“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.”

Huh. What is a “large scale issue” in this context? Why can’t WCAG 2.0 handle it?