Contributing to Gutenberg

I realized how important WordPress’ Gutenberg project would be as soon as I saw it. Internet publishing has been in a weird place from an authoring and design standpoint for some time; the penetration of mobile devices fundamentally broke the WYSIWYG document model, and WordPress needed to modernize to meet the publishing experiences of modern platforms like Medium and Squarespace.

As a part of WordPress’ Accessibility Team, I contributed my expertise in user experience, user interface design, and accessibility.

Document Flow

Gutenberg breaks individual pieces of content into blocks. This decision had some advantages and disadvantages, but ultimately, it makes the editor feel heavy and clunky. Asserting content as blocks was a reflection of the system, not the content people are building. As early as version 2.6, I proposed reducing the amount of block interface overhead by keeping text-like content as one cohesive piece of content, as demonstrated:

A wireframe showing how Gutenberg treats every piece of content as blocks, with a proposal to treat consecutive text items as one cohesive block.

There are two distinct advantages to this approach. First, it maps to the majority of document editing experiences that many users have. It’s familiar, and you don’t need to know that two separate paragraphs are actually blocks. Second, by grouping similar content together, the amount of UI overhead is reduced.

By reducing the amount of overhead and staying predictable with text editing, the design also supports established accessibility norms for screenreaders and relays less meta information to those that are using assistive technologies.

One side effect is that this model also forces content creators to work within the Gutenberg model of document publishing. Speaking from my own workflow, I tend to outline posts using levels of bulleted lists before expanding those thoughts into full paragraphs. It’s how I prototype content quickly. It works in Word, Apple Notes, WordPress’ Classic Editor, and almost every other document editor that I’ve encountered. To replicate that here, I’d have to create a bulleted list type, copy each bullet, paste it into a paragraph block type, and then format from there. I have adequate fine motor skills (and patience), but this would be a tremendous challenge for users of assistive devices.


My goal for contributing to Gutenberg’s interface design was to focus on creating and publishing content in a way that was simple, direct, and pleasant to use. In content editing, I think it’s important to keep the publisher close to the content that they’re creating, i.e., manipulating words and media directly and not diving into submenus and other non-direct editing contexts. Where this went wrong, in my opinion, is the interface surrounding (literally) blocks and the focus on blocks instead of content.

As previously mentioned, everything is a block and each block has a significant amount of interface that is associated with it:

There are icons on the perimeter, icons on hover, icons that are shown but grayed out. The massive amount of UI is taxing on sighted users, and all of this interface needs to be made available to assistive technologies as well. My primary concern was that the amount of interface takes away from the focus on content and its creation; again, we’re making content, not blocks. In the screenshot above, the content doesn’t even exist yet:

Here, the entire boundary of this block has interface elements to manipulate an object that doesn’t even exist yet. The UI should be more intentional when adding an image to do just that – add an image. Once the image is added and selected, I think there’s a better opportunity to expose more options such as linking, positioning, deleting, replacing, and so on. There just needs to be some consideration for context.

My comment on an issue in GitHub discussing UI in Gutenberg

Another interesting case of too much UI came up with embedding external content. There are any amount of external sources that you may add to a post (Twitter, Instagram, RSS, etc). My recommendation was to have a single Embed block type that took some information and made the embed for you:

A wireframe showing a possible alternative embed content block type in Gutenberg.

Alternatively, pasting in a link anywhere within the document editor should try to convert it to its embedded content type. Other services do this, and it requires much less to execute.

Another example of the focus on blocks instead of content:

Two highlighted paragraph boxes in the Gutenberg editor.

When selecting text between two paragraphs, you don’t select from text boundary to text boundary. Instead, you select the two blocks in their entirety. This is a unique and unprecedented behavior.

Here’s a Twitter thread with some of my compiled thoughts about NUX, the interface, and overall user experience within Gutenberg.


A lot has been written about the shortcomings of Gutenberg as an accessible product, ranging from the technical aspects of its design to product management in open source to WordPress’ community governance.

I can offer this summation. Technically, Gutenberg will most likely check the boxes of WCAG 2.1/AA. Automattic and community developers spent a lot of time ensuring their submissions had ARIA labels, semantic HTML, and other technical a11y considerations. But, the challenges with Gutenberg’s accessibility were deep in the product design, and no amount of ARIA or WCAG alerts could relay why Gutenberg isn’t pleasant to work with outside of a mouse/keyboard experience. For that, you would need to turn to usability tests and benchmarks against other editing experiences.

The accessibility challenges are, in my view, the same issues that impact the sighted experience but much less difficult to ignore. For example, tabbing through the block interface means you have to enter/exit each block of content; with a post such as the one you are reading, that’s a large number of elements to navigate. Then, you have to enter the block to begin editing, at which point the large amount of UI controls are announced to you.

One of the goals of the project was to make content publishing easier. That’s a big problem to solve, but in this case, research needed to be done to understand how content publishing is conducted across different technologies and contexts. Valuing and understanding that information from the outset would have resulted in a vastly different (and much more accessible) product.

Leave a comment

Your email address will not be published. Required fields are marked *