Some Gutenberg Accessibility Clarifications

October 18, 2018

Topics: Accessibility, WordPress.

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.

  1. Too little, too late.

    We’ve been begging for React development assistance focused on accessibility since the beginning. 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. Having Matthew MacPherson working full-time on Accessibility concerns is brilliant, and he’s been able to accomplish a lot – but why couldn’t something like this happen sooner?

  2. 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.

  3. 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.

  4. 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.

Have something to contribute?




« Read my Comment Policy

7 Comments to “Some Gutenberg Accessibility Clarifications”

  1. Yeah they pushed this out too fast. Thanks for the write up post about the issue.

  2. @Jen Gutenberg does still have a “Classic” block option and a code editor view that are considerably simpler to use. But it definitely prioritizes the visual/block editor experience in a significant way. If you switch to the code editor, however, it will default to the code editor in new posts & when editing posts previously created in Gutenberg.

    If you edit a Gutenberg post in the code editor, however, you may lose the ability to edit that post using blocks if you break any of the comment indicators that define the block separations in the code.

  3. Thanks Joe, appreciate the follow-up and will stand by for your post. In the meantime, I’ll get the plugin just to be ready. Thanks again.

  4. Everything about this is turning me away from WordPress My main problem with all of the is I’ve always hated using the visual editor and preferred hand coding everything – but I was also making mostly text posts… Gutenberg seems to require that you use the visual editor becaus of all the the extra code it adds in to make the blocks…

  5. Joe, thanks for such an insightful post. As a blind WordPress user, I’ve sort of been loosely following threads around Gutenberg, but I had no idea its release was so imminent. Very unfortunate that more progress won’t be made before release, but maybe the grater WordPress team will take this as a learning opportunity, an opportunity to realize just how important it is to dedicate appropriate development resources to accessibility early enough in a project. Silver linings aside, I wonder if there might be a way for us to revert, even if temporarily, to the current editor? If not, maybe there are other methods that can be used to post to WordPress and while far less than ideal, at least this would prevent some of us from being locked out of WordPress authoring entirely. Again, thanks for clarifying relevant points in this post.

  6. I’m working on a post to address that question, but I’ve had to rewrite it multiple times this week due to the rapid pace of change.

    The short answer, for your situation is that I would recommend installing the classic editor plug-in and allowing the upgrade to WordPress 5.0. The classic editor plug-in is a seamless integration that will behave like you’re accustomed to.

    The post I’m working on will address the topic in a more extended and thorough manner.

  7. As a blind WordPress blogger and podcaster, what should I do when WordPress 5 is released? Should I just hold off on the upgrade because of Gutenberg? If not, will the classic plugin work? Are there other options, such as the ability to directly paste in HTML (HyperText Markup Language) or markdown?

    I’m trying to decide if it is worth sticking with WordPress, or I should move Blind Access Journal over to another CMS (Content Management System) such as Drupal.

    Thanks,

    Darrell