I have, for the most part, remained silent about the whole WordPress Gutenberg accessibility topic. Others who are closer to the project have been very vocal about it, and continue to do so. However, after a period of sickness, and now returning to more regular blogging, I feel the time has come to break that silence.
What is Gutenberg? 🔗
Gutenberg, or the new WordPress block editor, is the next generation writing and site building interface in the WordPress blogging platform. WordPress has evolved to a full content management system over the years, and this new editor is becoming the new standard way of writing posts, building WordPress pages, and more.
The idea is that, instead of editing the whole post or page in a single go, and having to worry about each type of element you want to insert yourself, WordPress takes care of much of this. So if you’re writing an ordinary paragraph, a heading, insert an image, video or audio, a quotation, a “read more” link, or many other types of content, WordPress will allow you to do each of these in separate blocks. You can rearrange them, delete a block in the middle of your content, insert a new block with rich media etc., and WordPress will do the heavy-lifting for you. It will take care of the correct markup, prompt you for the necessary information when needed, and show you the result right where and how it will appear with your theme in use. It is a WYSIWYG (what you see is what you get) editor, but in much more flexible form. You can even nest blocks and arrange them in columns nowadays.
Gutenberg also supports a rich programming interface so new blocks can easily be created, which then blend in with the rest of the editor. This is supposedly less complex than writing whole plugins for a new editor feature or post type. Imagine a block that adds a rich podcast player with chapter markers, show notes and other information, and you can easily embed this in your post or page where needed. Right now, this is a rather complex task. With Gutenberg, designing, arranging and customizing your content is supposed to become much easier and flexible.
The problem is complexity 🔗
So the main problem from the beginning was: How to make this seemingly complex user interface so simple even those who cannot code or have web design skills, can easily get around it? WordPress does several things to try and accomplish this. It focuses on each block individually and only shows the controls pertaining to that block. Everything else shrinks down so it doesn’t distract the user.
However, since its inception, the problem was that not everybody was on board with the notion that this editor should work for everybody from the start. In theory, the project leads were, but they were impatient and didn’t want to spend the extra time during the design phase to answer the hard questions around non-mouse interactions, keyboard workflows, non-visual communication of various states of the complex UI, etc. Accessibility was viewed as the thing that “held the web back”, or “could be added later”.
Fast-forward to the end of 2019, and it is clear that full accessibility, and therefore full participation in the experience, is not there yet. While there have been many improvements, there are still many gaps, and new challenges are introduced with almost every feature. But let’s take a look at what has happened so far.
A little bit of history 🔗
In March of 2018, some user testing was performed to evaluate the then current state of Gutenberg with screen readers. The accessibility simply was not there then. This is made evident by this report by the WordPress Accessibility team, a group of mainly volunteers who have made it their goal to try and keep on top of all things accessibility around WordPress and Gutenberg.
The whole state of affairs became so frustrating that Rian Rietveld, who had led the WordPress accessibility efforts for quite some time, resigned in October of 2018. Her post also covers a lot of the problems the team was, and from what I can see from the outer rim, still is, facing every day. The situation seems a bit better today, with some more core developers being more on board with accessibility and more aware of issues than they were a year ago, but the project lead, and the lead designers, are still an unyielding wall of resistance most of the time, not willing to embed accessibility processes in their flow from idea to design to implementation. Accessibility requirements are not part of the design process, despite the WordPress codec saying otherwise:
The WordPress Accessibility Coding Standards state that “All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.0 at level AA.” Taken from the WordPress Accessibility main page.
One thing that might have helped with awareness a little is the WP Campus Accessibility Audit for Gutenberg, done by the Tenon.io team in early 2019. That report is worth a read, and the links to the open and closed issues uncovered by this audit show how much progress has been made since then. But even that report, publicly available for everybody’s scrutiny and verification, has not managed to reach the project leaders.
My personal take 🔗
I am by no means a deeply involved member of the WordPress accessibility team. I am mostly a WordPress user who may have a little more web accessibility knowledge then many other WordPress users, and a day job that requires me to work on other stuff. But what I see here is a repetitive pattern seen in many other projects, too. Treating accessibility as a bolt-on step at the end of any given cycle never works, will never pay off, and never lead to good inclusive results. The work to get this done is much harder than implementing and thinking about accessibility from the start of the project or sprint.
I love the Gutenberg concept. I think concentrating on a single block and getting that right without having to worry about other paragraphs or bits in your post is fantastic. And being able to rearrange your content without fiddling with copy & paste and messy formatting is a totally awesome experience. I use Gutenberg while writing this post, have used various block types throughout, and am getting around the UI quite well. But I also am not the average user. I am very screen-reader-savvy, well experienced in dealing with accessibility quirks and odd behavior, focus loss and other stuff web accessibility shortcomings throw at me every day. Although the experience is much better than it was half a year ago, it is still far from perfect. There are many flaws like the editor not communicating the mode it is in, navigation or editing, and other dynamic complexity that is still so inconsistent sometimes that it might drive one up the wall. But the ideas and broad concept behind Gutenberg itself is totally sound and will move the web forward.
The one big sad and frustrating thing about it is, again, that we as the accessibility community have to fight for participation. We are not included by default. In numbers, that’s roughly twenty percent of the U.S. population that has a permanent disability of one form or another. And that’s not counting temporary disabilities like a broken arm. The self-set accessibility guidelines for the WordPress project are being ignored in the Gutenberg case, as if it was a separate project. And even though discussions have happened, the mindset hasn’t changed much in some key positions. The fact that a bunch of currently fully able-bodied people have actively decided to not be inclusive from the start means that a lot of decisions requiring a certain amount of both empathy and expertise need to be made at lower levels, and pushed into the product via grass root methods, which are often long and cumbersome and only lead to slow results. These can be very tiring. Rian Rietveld resigned as the leader of the accessibility effort in WordPress over this, to preserve her sanity and health, and others might follow.
Some would probably now argue that WordPress and Gutenberg are open-source projects. But you know what? Automattic, who makes quite some good money from these open-source projects, is a company that could easily throw enough monetary and personnel power behind the effort and make accessibility a top tier priority. I’d say hiring a product lead, and a designer who know their stuff would be a good starting point. Proper training for all designers and engineers would be another step. And it’s not like they wouldn’t get anything in return. They sell subscriptions to hosting blogs on WordPress.com, they sell subscriptions for Akismet and Jetpack, which are both plugins without whose self-hosted WordPress would be lacking a lot of functionality nowadays, so those improvements they make to that open-source software of which they are the project owners would feed right back into their revenue stream. Lack of accessibility never pays off.
And a recent update to the theme customizer shows that accessibility can be achieved right when the feature launches. The way one can arrange widgets and customize other bits of one’s design is totally awesome and helps me and others tremendously when setting up a site for themselves or customers. So, it can be done in other WordPress areas, it should be done in Gutenberg, too!
So here’s my public call to action, adding to what people like Amanda have said before: WordPress and Gutenberg project leaders: You want WordPress to be a platform for everyone? Well, I’d say it is about time to put your money where your mouth is, and start getting serious about that commitment. It is never too late to change a public stance and get positive reactions for it. The doors aren’t closed, and I, for one, would whole-heartedly welcome that change of attitude from your end and not bitch about it when it happens. Your call!