First Reactions to Gutenberg

A big reveal at WordCamp Europe was Gutenberg, an inline WYSIWYG editor for WordPress. While I had first seen it at WordCamp London, it was not a public project yet. As of WordCamp Europe, it is now in open beta with a plug-in available for testing.

I am not involved with WordPress, though I have gotten to know some of the folks on the accessibility team (surprise), so my knowledge of what is going on behind the scenes is zero. What I have to go on is the demo plug-in, an interview with Matt Mullenweg, some hallway conversations, and nearly 20 years of experience with content management systems (including having built one that pre-dated WordPress and was in use for 15 years until I moved on from my company).

Given all this, I am wary of the justifications for the tool. Add my accessibility experience and I am wary of its successful implementation. I am going to try to quantify what is in my head and hope it is useful for me in the future and perhaps someone else today.

Feature Creep

When I first heard about Gutenberg, I asked some people at WordCamp London and later at WordCamp Europe who had requested it. Remembering that WordCamp is open source, I then re-jiggered my question and asked what problem it was trying to solve.

Of the people I asked, I do not know who was a contributor. The answer I overwhelmingly got back was that Matt wanted it. Matt Mullenweg is one of the creators of WordPress and is also founder of Automattic, a company that has built its business on WordPress, and also contributes mightily to WordPress.

Listening to Matt

I watched Matt’s interview about Gutenberg with keen interest as a result of these conversations. I wanted to understand both what problem Gutenberg is trying to solve, and how it will do so. You can watch the entire interview (no captions yet) on WordPress.tv and I have embedded it below (no captions here either). Update: As of November 3, 2018, I paid for captions and added them on this embed, as well as submitted them to WordPress.tv.

Some of the reasons he offered were about the complexity of shortcodes and widgets, though it is not quite clear how Gutenberg solves that any better than finally adding the WYSIWYG editor to text widgets, for example.

But I keyed into a question about the impetus for the new editor, and what I heard from the answer was that Wix, SquareSpace, Weebly, and others are competition that must be addressed. It feels to me that addressing that competition starts with mimicking their interfaces.

There are also lots of assertions that it will be easier to make rich, interactive pages. Using the Bloomberg interactive history of code example, Matt suggested that Gutenberg would make it easier to achieve content like that. While he acknowledged that was a stretch, the concepts of easier and richer kept popping up.

My Bias

I built (not alone), implemented, trained, and supported a content management system for fifteen years. It pre-dated WordPress. When WordPress started to get feature parity in the core product in 2015, then I worked with WordPress as well. Over the years I also worked with many other content management systems.

In 2012 (roughly) I remember bringing a prototype of a new content editor to one of my user groups. My user groups were made up of our clients, specifically the content authors who were in the platform on a regular basis. When I proudly showed off an editor that looked very much like Gutenberg does today, the resounding feedback from my users was that they were not interested.

Granted, these were business users. Users who sometimes crafted content outside of the CMS and then pasted it into the WYSIWYG bucket. The new model did not appeal to them. They wanted an interface that was analogous to Microsoft Word — edit a document as a whole, not piecemeal.

Our users were not as diverse as WordPress users, even five years ago (an eternity in web terms). But what we learned was that we were trying to solve a problem our users weren’t having. We wanted to add a feature nobody requested.

As such, Gutenberg feels familiar to me, particularly given its stated justifications after watching that interview.

User Experience

A lot of assertions on ease of use are made on the Gutenberg plug-in page, with nothing to back them up. Frankly, that page is not the place to do it anyway. But I keep hearing and reading these same assertions without any pointers to user research, usability studies, or any supporting data. Here is content from the plug-in page (many users’ first encounter with any background on Gutenburg), emphasis added:

The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.

The new post and page building experience will make writing rich posts effortless, making it easy to do what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

WordPress already supports a large amount of “blocks”, but doesn’t surface them very well, nor does it give them much in the way of layout options. By embracing the blocky nature of rich post content, we will surface the blocks that already exist, as well as provide more advanced layout options for each of them. This will allow you to easily compose beautiful posts like this example.

Even looking at the linked example, there is nothing on that page that cannot be done today in the current editor. I also do not consider that to be rich; it is plain text content and some pretty photos (without any useful alternative text). The visual appeal is from the CSS, not Gutenberg.

In short, it reads like a feature trying to justify its existence.

Use Cases That Worry Me

Inline WYSIWYG editors remove some features that my clients used to rely on, some extensively. The ability to run a full-page find-and-replace, the ability to quickly paste large chunks of content, and other edits that impact chunks of content that span the discrete blocks Gutenberg otherwise enforces.

In addition, there does not (yet) seem to be a way to handle nested chunks of content. For instance, in this very post I have <figure> elements that hold <video> or <blockquote> elements. So far, that does not seem possible. I expect that to change.

In my (now defunct) CMS, we used CKEditor. We had the ability to add pre-defined CSS classes to the styles menu, or even create custom buttons. I know TinyMCE offers the same features. How these will be supported, contextually, is still unclear. But they will need to be there.

It is not clear how meta boxes will be supported. This does not just impact plug-in developers (think of the pile of meta boxes that the Yoast plug-in adds), but it also impacts theme developers who add meta boxes for special client cases. What would suck is if everyone has to re-write their meta boxes when Gutenberg is released.

While Gutenberg may feel like a page builder, it is not that either. But developers and authors may carry those expectations into this new interface, so it needs to account for those interactions and gently guide users into or around them.

Accessibility

This bit is tricky. Gutenberg is brand new. There is a lot happening and code is changing constantly. As it stands today, Gutenberg is completely and utterly inaccessible.

That is not necessarily a problem. During the contributor day (where I hung out with the accessibility team) I had the pleasure of speaking to Joen Asmussen, one of the leads on Gutenberg. He reaffirmed Gutenberg’s goal to honor WordPress’s commitment to WCAG 2.0 AA. When I offered a fix for an issue, he already had that fix on his radar. That is awesome.

What is less awesome, and might be a problem, is that Gutenberg is slated to premier in WordPress 5.0. While no date is set, following the WordPress 3-4 month release schedule puts 5.0 somewhere in the first quarter of 2018. Or about nine months from the publish date of this post.

As someone who consults on accessibility remediation and sees clients tackle projects at this scale with dedicated teams, I can tell you that time frame is tight. And “tight” is putting is gently.

My job as an accessibility consultant is not to tell developers they cannot do something novel because of accessibility concerns. My job is to help them make that novel interaction accessible. This will be a heavy lift for the accessibility team, particularly if that team is not defining patterns up front, but is instead trying to fix inaccessible code in a constantly shifting code base.

WordPress Consultants

There are people at all levels of ability who implement WordPress sites. Some make custom themes and tweak PHP files. Some stack dozens of plug-ins into a single site instead. Some can read the small print on pill bottles or dunk on an NBA player, others may have disabilities. All of them earn a living building WordPress sites (or at least supplement their incomes doing it).

My fear is that Gutenberg will be the default experience and everyone who has clients on WordPress will need to support it. If Gutenberg is not completely accessible at launch, then it runs the risk of leaving some of these implementors out in the cold.

If, as a client, I ask my contractor for support with Gutenberg or help implementing a feature, but my contractor cannot help because she cannot use all the features of Gutenberg, then perhaps I will look for a new contractor.

There is a genuine risk that Gutenberg will cost developers with disabilities money from lost billable hours as clients shift to developers who can use it. There is also a risk that those on thin margins may find those margins thinning even more if they are struggling with an interface that, while technically accessible, is still unusable.

WCAG Compliance as Lip Service (Added June 29, 2017)

In reading another Gutenberg post (posted on the same day as mine with a similar title) by Mark Root-Wiley, I saw this quote from Matt Mullenweg:

We, for often very good reasons, do things like say WordPress is WCAT [sic] compliant and no new code should come in that is not. That’s a tradeoff, and that’s a tradeoff that we’ve enshrined. We should readdress it if we think that that tradeoff, whether for a particular feature, a particular user experience, or a particular benefit, is worth it.

The phrase do things like say WordPress is WCAG compliant fills me with dread. It diminishes the commitment to WCAG and all the effort from those who got WordPress to that point. It treats it as a talking point, not a hard-and-fast rule. It sets the tone for dismissing that commitment.

The very next phrase essentially dismisses that commitment: We should readdress it […] for a particular feature […].

Yes, I edited the quote by exclusion. I distilled it to the implied meaning, however.

I think it is pretty easy to get the message from his statement that WordPress is willing to dismiss its users with disabilities (permanent, temporary, or situational) in order to push Gutenberg forward.

That would be a shame.

Future Considerations

I actively push clients away from Weebly, SquareSpace, Wix, and others of that ilk. I send them to WordPress. I do this because the other platforms are inaccessible and I will not put my clients at risk by providing an inaccessible interface to their staff or partners (it is also just plain wrong).

If WordPress moves to Gutenberg as its default interface with no way to fall back to the original editing interface, I will likely also move WordPress into the recommend against bucket. And that would suck.

At the very least, for my site I will disable it. As it is, I do not use the built-in WYSIWYG here. I have disabled it completely because I want to break my code by hand.

Related

These are some of the posts about Gutenberg that have come across my radar.

• Gutenberg and Yoast SEO was the first post I saw, being written during the announcement, and it raises accessibility concerns right out of the gate.
• Random Thoughts on Gutenberg is essentially a quick reaction and bug reporting post.
• Gutenberg With A Screen Reader: Initial Thoughts And Reactions confirms what I said above for one type of user — it is currently inaccessible.
• Diving Into the New Gutenberg WordPress Editor (Pros and Cons) offers screen shots for some of the features, in case you do not have a dev site to install the plug-in.
• A First Look at Gutenberg Editor for WordPress: Mixed Opinions is another screen-shot-heavy review of the new editor.
• Improving WordPress Pt 4 – Where Gutenberg Lost Me (Open Letter to Core) raises a series of technical issues, most of which I didn’t even reference in this post.
• First Reactions to Gutenberg, the Future of WordPress raises some issues that annoyed me, such as the need to double-Enter, leaving empty content blocks at the end, and a menu bar that gets in my way.
• The State Of Advanced Website Builders is not about WordPress, but is about those things I think Gutenberg is mimicking (Squarespace, Wix, Weebly, The Grid, …).

I also encourage everyone (especially the development team, though I suspect they are) to follow the reviews on the plug-in page.

Update: July 5, 2017

I missed this last week, but @wptavern cites my Gutenberg post a bunch in its article “Why Gutenberg?” wptavern.com/why-gutenberg

Update: July 9, 2017

There is an ‘issue’ open against Gutenberg which is nothing more than links to articles reviewing Gutenberg. Great collection, feel free to add more.

Update:October 5, 2017

Yoast asserts Gutenberg is not ready due to meta box changes & accessibility issues, notes timing. Suggestions: yoast.com/gutenberg…

Update: September 1, 2020

Joe Dolson from the Make WordPress Accessible team gave an update at WPCampus Online on the ongoing work on the results from the Gutenberg accessibility audit (commissioned by WPCampus in late 2018 and delivered on 1 May 2019).

In 15 months the team has managed to work through two-thirds of the tickets, or 66 of them. While an impressive amount of work has been done by such a small team, let’s not forget how this is all clean-up from the two years of warnings prior to the Gutenberg launch that this would happen.

Automattic did not fund this audit, though it did donate some money, and Automattic is still relying on volunteer accessibility experts to do the work to make its platform legally viable for many of its customers. Remember, Automattic is a three billion dollar company.

A full transcript is available at the session page.

You can see open issues in Trac and on Github.

Update: September 25, 2020

As the W3C has embarked on a full web property rebuild, its vendor (Studio24) indirectly announced earlier this month that it had dropped WordPress from consideration as a CMS. WPTavern took issue with this yesterday, and Studio24 responded today, (politely) pointing the finger squarely at Gutenberg.

Part of WPTavern’s argument was that the selected platform (Craft CMS) is not open source software (OSS), though WordPress itself is not completely open source in practice (Slack versus IRC or MatterMost being the easiest example). More importantly, Gutenberg itself was not truly open source in process — Automattic drove it as a business decision reaction to the growth of Wix, Weebly, and SquareSpace.

Studio24 cited accessibility as the deciding factor. Automattic has already signaled accessibility is not a priority for it or its investment in Gutenberg. The community had to crowd-fund an audit, all while Gutenberg was pushed to final public release with dozens of known accessibility issues. The entire time, all the accessibility work was done by volunteers, not supported by Automattic’s $3 billion bulk in any meaningful way.

As Gutenberg works to replace some common plug-ins with its own features (think ACF), any code written today that uses the features of those plug-ins has a built-in expiration date. Even as Gutenberg’s scope continues to shift, the same confusion we saw over meta boxes will likely appear in other core WP features, warranting unanticipated code changes. This is an unnecessary and unknown future cost to the W3C.

By using a smaller platform (which has already made a public commitment to WCAG), the W3C has more leverage to force WCAG / ATAG compliance. It can do this in the contracts, where payments are tied to compliance. With WordPress, there is no way to do that. All accessibility work comes from the community; there is no way to enforce it.

Given the past behavior of Automattic (which predicts future actions) versus the published (and contractually obligated) commitments from Craft CMS, the W3C made the right call. It is an unfortunate black eye for OSS, and an unforced error on the part of Automattic that got us to this point, but here we very publicly are.

Related from me that informed this hot take:

• This post you are reading;
• Lessons from Gutenberg (2018);
• A Model for WordPress Accessibility (2019).