Thoughts On “Gutenberg and the WordPress of Tomorrow”

I’ve been waiting for this talk to go up on WordPress TV because I missed it when Morten first delivered it at WordCamp US. It’s no secret that I have a hate-hate relationship with WYSIWYG (What-You-See-Is-What-You-Get” editors for the web. Part of that is because I think if people are going to build websites, then they should learn foundational web technologies deeply. Part of that is also because literally every single one of these editors, when placed in a web context, has been completely inaccessible. I’m including page builders in this, because the problem they’re trying to solve is the “What-You-See-Is-What-You-Get” thing, but for people who aren’t developers. I started working with things on the web back in 1998. That’s a long time ago. Every single WYSIWYG editor and page builder I’ve encountered from that day to this has proven me right. Geocities page builder. Yahoo page builder. The website wizard that ships with Cpanel. Squarespace. Strikingly. Medium. Beaver Builder. Visual Composer. Wix, (except for that one time they borrowed code from the WordPress.com app). Every single one of these, along with every other similar thing I haven’t named, has been or is unuseable if you use assistive technology, or even just don’t use a mouse. When Gutenberg first came on the scene as a plugin in beta, I tested it twice, and was absolutely certain that it would be just like all the others. I kept hearing, “We’re going to make it accessible,” to which my response, (at least internally), was “Sure you are. Just like all the others who talked about how important accessibility is, only to leave it out when it came to the editor/page builder.” My initial tests cemented that response. I wasn’t alone when it came to being highly skeptical of Gutenberg and accessibility.

And then, things started changing. The Gutenberg developers were serious about making sure Gutenberg is accessible to everyone, with the best example so far being the demmo at this year’s State of the Word highlighting what I’ll refer to as color contrast guardrails. That’s not cosmetic accessibility. It’s not something like “we added some read-aloud kind of feature and a font resizer and: Magic! We haz accessibility now!” The Gutenberg experience still isn’t great when it comes to accessibility. There’s still a lot of work to be done. But Gutenberg is proving me wrong with regard to WYSIWYG editors, and I’ve never been more happy or more proud to be wrong in my life. This is actually happening. There’s actually going to be an accessible visual editor. People with disabilities are going to get to play on the same playground as everyone else is for once. We finally get to play in a world that everyone else has played in for the last twenty years, and this makes Gutenberg genuinely exciting. It’s vital though that Gutenberg is properly documented for screen reader users. First, WordPress has to establish trust with a group of people who have years or even decades of experience of being burned by these kinds of editors. That may not be fair to WordPress, but if WordPress is entering this space, it’s now in the position of having to clear away the baggage left behind by everyone else, and people who use screen readers have very long memmories when it comes to these sorts of things. Merely saying “Our thing is accessible” is not enough. I didn’t believe accessibility was going to be taken seriously, and that’s despite being a member of the WordPress Accessibility Team and having a bias in favor of WordPress for which I’m famous. Convincing anyone else that we mean it when we say this is useable by everyone regardless of whether or not assistive technology is involved is going to take work, and part of that work is going to be convincing people with disabilities to make that leap while trusting that what’s on the other side isn’t going to be the same old song and dance that’s gone on for the last twenty years. Second, the steps that everyone else has been gradually making over the last twenty years with regard to WYSIWYG editors and page builders are all going to be combined into one giant leap for people who use screen readers, because the workaround when you can’t use a visual editor is to rely on a text-based one, whether that’s copying and pasting from a text file or switching the TinyMCE editor to text mode in WordPress. People who use screen readers are now going to have to integrate all the visual concepts, along with the technical aspect of controlling them. We’ve been able to avoid doing that, unless we’re web developers, at which point we then start wrestling with CSS. But if you’re not a web developer and you’re focusing on using software like this, until Gutenberg, you’ve been able to almost completely avoid dealing with visuals, unless you’re doing something like choosing a theme or adding images to a post or page. Otherwise, it’s text whenever possible. Changing the status quo this much, without documentation to aid the transition for people who use screen readers, ensures that as a user group, we are not likely to make the leap, unless we have a pressing need to do so. As a whole, we’ll just switch to a different platform with less advanced editing, or, if we don’t already have websites, just not have a website at all and use Twitter or Facebook to create content on the web. Personally, I’m willing to make the leap, and help others do the same. I want everyone to participate in the WordPress of tomorrow, to continue to have the ability to choose whether or not to own their own data, ETC. But I have a vested interest in WordPress. I want everyone who wants to use WordPress to be able to keep up with the changes that are coming without having to make a choice to add content to their websites that’s based on “How much mental and emotional energy am I going to have to put into this?” That’s not going to be possible unless there is proper documentation to go along with the software.