In a recent email, I wrote this paragraph (paraphrased because it’s out of context):
“Accessible development requires a high level of distrust for the tools you’re using to build a site, and an operational assumption that unless you have reviewed the output of a tool, you should assume it’s not accessible. This is a frustratingly adversarial method of interacting with software, but once you’ve worked through the process of assessing what your tools do systematically, you will have a good representation of what you can and can’t use from those tools.”
Writing this sentence made me really think about my interactions with WordPress and how I approach the future of WordPress and blocks. That, coupled with a recent read of Dan Devine’s article “The Complicated Futility of WordPress”, gives me some interesting thoughts.
First, it’s interesting seeing complaints from developers about the idea of “chafing” against assumptions in software. As a developer of accessible web sites, that friction has always been a part of my development practice. It’s just part of the process – because I’m fundamentally approaching my tools with a low level of trust.
This isn’t something that’s come into existence for me with the introduction of the block editor; but it has changed how I deal with things.
Site-building tool problems
One of the fundamental challenges with any site-building tool is that you’re losing control of the output HTML (HyperText Markup Language). This is true for Elementor, Beaver Builder, Gutenberg blocks, or any non-WordPress site builder. Instead of writing code, you have settings to configure, and each tool will implement the outcome differently.
For accessible development, this is one of the number one barriers: before you can use anything, you have to assess what it will produce. You have to know how the settings will change that feature, and which settings in which elements will raise accessibility barriers.
Damn, that’s a lot to deal with. I’ve audited sites built with numerous different tools. With all of those sites, the challenges in remediation and in long-term maintenance become much more difficult.
But…this isn’t really a new problem.
Widgets, plugins, and themes, oh my
WordPress was already built on a stack of blocks under other names, and all of those had the same potential to raise accessibility problems. Everything you can just drag into place and configure with settings is a potential source of issues. Knowing to tell clients that they can’t use the category archive widget if it’s configured as a dropdown was just part of the training process.
Themes make a whole host of decisions about how a site will work that also cause potential barriers. Navigation, DOM (Document Object Model) structure, and contrast choices are at the top of my list, but there are hosts of potential issues from themes.
The block editor (and full site editing) means that there’s more of this. Same issues, but more of them. As a result, while the block editor can create some frustrations (I’m looking at you, table block), those aren’t really new frustrations. It’s not like the classic editor was able to create accessible tables, after all.
Full Site Editing, what?
And we come down to the newest shiny feature in WordPress: full site editing. People love it, people hate it. I’m personally more on the hate it side of that – but I don’t anticipate it having any significant impact on my development habits. Nothing that the full site editing suite does seems like a feature I would use or want my clients to use.
Full site editing should absolutely be worked on until it provides the most accessible editing experience and the best possible outcomes for the front-end. This is unlikely to change the way I work, however.
Full site editing is really about giving users more power to manage their own sites. It grants more access to tweak colors, layouts, spacing, and manipulate the elements of a site, for better or for worse. But I don’t need those tools, and giving clients the ability to make those changes just means a longer list of things I have to tell them not to do or disable on their sites.
But it’s also fully optional. If, at some point in the future, WordPress abandons classic theming, then that’s the end of my relationship with WordPress. But adding a new feature that I am fully able to ignore doesn’t feel like a threat.
The future of WordPress
The reason I’m comfortable continuing to work with WordPress is not because it’s able to provide a magically accessible site. It’s because I have put in the hard work to know what I can use and what I can’t. I have a reasonably good handle on plugins that work out of the box, plugins that are flexible enough to work with, and plugins I should uninstall and replace right away. That’s always a moving target, but because I keep working in this space, I’m able to mostly stay on top of it.
I think it’s unlikely that WordPress will abandon classic theming, and I don’t think there’s any reason that it would. There’s nothing about adding a new type of theming layer that requires changes to the old one.
In the end, my highly quotable opinion about full site editing:
“Full site editing? I can’t see any reason I’d use it. But it doesn’t get in my way.”
Have something to contribute?