Gutenberg Accessibility Costs WordPress the W3C Work

This is a slightly extended version of my Twitter thread.

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.

A Simpsons cartoon rendition of a large machine that is similar to a wood chipper. On one side is a large metal funnel, on the other is a chute. The face has a plate that reads Anti-Gutenberg 3000. It is covered in dials and lights and has an LED screen labeled Temperature that currently reads 451° F.

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:

Update: 26 September 2020

Amanda Rush offers some experience with clients who use Gutenberg (none of mine do) and takes issue with WPTavern’s attempt to shame W3C over a non-OSS choice in her post “W3C Is Prioritizing Accessibility Over Its Open Source Licensing Preferences”. Why is that a bad thing again?.

Update: 27 September 2020

Joe Dolson makes a great point in his post The W3C Drops WordPress from Consideration, namely that WordPress is not a good platform for internationalization. Given the scope of the W3C, this is kind of a no-brainer.

I am also a bit embarrassed I did not consider that given I ran a CMS where one of the main selling points was its support for internationalization and back then I knew WordPress could not handle double-byte characters. Perhaps I assumed such a massive project might have sorted that by now.

4 Comments

Reply

I manually clicked here to say thank you

bage; . Permalink
In response to bage. Reply

I wish they had given Joomla! 4 consideration. We’re doing a TON of work on accessibilty

Troy Hall; . Permalink
Reply

I’ve updated my post to include links to your post and Joe’s, and am also facepalming right now because the internationalization thing is something I was not thinking about when I wrote mine. I should be thinking about it, because (1) attempting to blog in Hebrew as well as in English on my own personal site is a thing that’s not going very well and I know exactly why (spoiler alert: Joe is right, in spades), and (2) WordPress’s inability to elegantly handle multi-lingual content is the reason I have one project which includes a third-party translation firm mirroring the updated site which means coordinating changes and making sure they’re accessible between the two on my part. So yeah, massive brain fail.

Reply

Personally, never been a huge fan of prioritizing accessibility from a source’s end, so not too bothered.

Jonathan; . Permalink

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>