Since the publication of the WordPress 5.0 release schedule and the ensuing hubbub about the accessibility of the new Gutenberg editor I’ve seen a lot of materials published in a panic about the future accessibility of WordPress. In that massive amount of content, I’ve noticed a few specific trends that I think need clarification.
Before I begin, I want to say that the opinions I’m about to voice are purely my own, and have not been discussed with the WordPress Accessibility team nor do they represent the opinion of the team on the whole, as far as I know.
Myth: Gutenberg has not received accessibility testing
This is not true, precisely. What has not happened is any thorough and systematic testing of Gutenberg. There have been tons of ad hoc tests performed by Gutenberg developers and by the accessibility team. Many of these tests have resulted in significant improvements accessibility. Some of them have resulted in the total replacement of a component within the editor.
The end result is that, right now, Gutenberg has many micro-interactions that have excellent accessibility. While there are still interactions that are not yet accessible, these are well on their way.
Where Gutenberg falls down is on the overall use of the system. 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.
But it is a gross misrepresentation to say that the new editor has not been tested for accessibility at all.
Myth: The new WordPress editor will break accessible content/create inaccessible content
No. This is simply not true. The entire conversation about Gutenberg is wrapped up in concerns about the use of the editor; the content itself is not a concern. While I have not personally checked the output of all Gutenberg blocks recently, I have confidence that those issues will be dealt with prior to release.
In fact, Gutenberg incorporates some very useful accessibility tools that can aid users in avoiding some accessibility pitfalls, such as poor contrast and improper heading structures. Gutenberg doesn’t prevent these issues; but it will help authors avoid them.
Myth: The Gutenberg team doesn’t care about accessibility
They do. 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.
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. 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.
So what, exactly is the accessibility team upset about?
There are four things that have the accessibility team particularly upset right now, in my opinion.
- Too little, too late.
- Attitudes matter.
There have been a number of statements floating around that are very concerning about the attitude towards accessibility. The statement that having an audit would not change the release timing makes it clear that accessibility is not considered a blocking priority, and this is tremendously disheartening.
- Rush to Release
Gutenberg has been in the works for almost two years. During that time, the entire community has waited for anything resembling a release schedule. While it’s well understood that there was a long early period where no release schedule was realistic, we were always hoping that at some point a release schedule would be set and would allow for time to review the complete product before release. Instead, we are abruptly informed that the release is set for six weeks away, despite not yet having frozen the user interface.
This timeline in no way allows the final product to have adequate testing. Testing for accessibility requires real device testing – the automated tests will not know that a perfect interaction in NVDA + Firefox is totally broken in JAWS + Edge or VoiceOver + Safari. The bugs can be incredibly obscure, so seemingly innocuous code changes yield unpredictably strange results. This happens routinely; and with a system as complex as Gutenberg, it needs review.
We need time.
How can we suddenly drop all other scheduled projects to dedicate all our time to Gutenberg with so little lead time? I normally work on a minimum of a 2-month lead time in my schedule. Sometimes it’s as high as six months. I have been trying to keep my schedule more open than usual so that I could put time in on Gutenberg; but I was never expecting such a ludicrously short time frame. This is a disservice to all WordPress volunteers. It explicitly forces us to choose between our clients and our passion project.
- Forests or trees?
Gutenberg has great trees. The forest, however, is a nightmare. We need to create navigable paths for everybody, so that the use of Gutenberg is actually pleasant.
I care deeply about the accessibility of WordPress for both users and authors. But it is irresponsible of me to not consider that I have bills to pay and obligations to meet.
If this same schedule – targeting a release of November 19th – had been set three months ago, and this drive to complete had started then, I think we’d be more happy. I’d still be very worried, especially based on where Gutenberg was three months ago – but it would have meant we had a schedule that I could plan for, instead of simply react to.
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.
The best solution would be to delay the release.