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 availablefor 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.
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.
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.
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.
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.
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.
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.
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.
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.
Graham, you raise a really good point. If the editor changes my HTML in any way (say, by wrapping <div>s around any blocks of content), then it is a non-starter for me. Not just because it may impact my styles (think headings and adjacent sibling selectors), but because it may confuse my clients who author both in HTML and WYSIWYG modes today.
Thanks for writing this post, Adrian. Admittedly yours is a lot more objective than my posts on the subject have been so far, and I think it’s going to be a while before I approach Gutenberg with anything other than frustration, and yes, anger. I also realize this isn’t necessarily fair Re: WordPress releases, I think I read somewhere, or heard in a talk, that 5.0 is supposed to be out by the end of this year, assuming something doesn’t get in the way. Assuming this is true, I’d call this more than ambitious. I tested the other day with the text version of Gutenberg, and it does indeed surround your text, but not with a div. I don’t have the code offhand but it’s an HTML comment with a wp-text-core tag, complete with opening and closing. So think start HTML comment plus tag, then close the tag, with another comment. Definitely not amused.
I’ve also started following the repo and will hopefully contribute. I’m a proponent of “don’t gripe if you’re not helping with the work,” and I have absolutely no intention of keeping my mouth shut as long as this thing is slated for core and in the state it’s in/the path it appears to be going down.
Amanda, I am unsure how the final implementation of the content blocks will be done and hesitate to assert that what I see today will be what is in the final release. But you are correct, right now it uses HTML comments (such as <!-- wp:core/text --> or <!-- wp:core/image -->).
At WordCamp Europe I was asking if they had experimented with data-* attributes, or some other approach that can be picked up in the DOM. My greatest fear is that <div> wrappers get used. Either way, the current comment approach feels too prone to breaking, but also not too far from shortcodes.