Gutenberg, accessibility, and compromise

The original text was published on Nov 16th, 2018 via the Post Status newsletter. We re-post with Brian Krogsgard’s permission. Thank you, Brian! And below, you’ll find a reading list on Accessibility & Gutenberg.

I had a call with Matt Mullenweg to discuss some things regarding the upcoming Gutenberg release, the critiques around accessibility, and thoughts I’ve had around the way this release and other releases are scheduled. I’ll keep this note to the accessibility components.

There have been ample critiques of Gutenberg, with a great deal of heat especially around the topic of accessibility (they’ve been documented in this newsletter). Rightfully, many folks want to see more work done around making Gutenberg accessible for all users. I think that some of the critique is overdone and the temperature is a bit too high around the topic.

I believe accessibility — especially for a tool as widely used as WordPress — is very important. The a11y efforts around WordPress have increased a great deal over the years. However, WordPress, nor the broader web, have a great record for releasing fully accessible features from day 1. Is there more work that can be done to make Gutenberg as accessible as it can be? Yes. Has the team building Gutenberg worked hard to make it accessible? Undoubtedly yes. Is WordPress accessibility in need of more work? Yes. Is there complete consensus around what proper accessibility even looks like in Gutenberg? Not as far as I know.

Shipping software is hard. Shipping feature complete software is impossible. Pleasing every party with a stake is impossible. I don’t envy the team developing Gutenberg, nor Matt leading the effort. I wouldn’t want to touch it with a ten foot pole.

There have been communication breakdowns, it appears, between accessibility advocates, accessibility volunteers, and Gutenberg development team members. I do not think Matt Mullenweg takes accessibility lightly; he told me so, as well. I think that the team working on Gutenberg wants to make it accessible for everyone to use. I think there is a lot of hostility in the air. A11y advocates are an under-represented group, and too many times have had to “fight” for accessible software. I think there is a lane here to not fight, but to work with, Gutenberg team members to move forward. There is, I think, room for compromise.

I think it’s important to continue to identify, work on, and improve accessibility in Gutenberg (and WordPress broadly). I personally, cautiously, suggest we embrace Gutenberg shipping without a complete accessibility audit while seeking more people to help with accessibility moving forward.

Gutenberg has been under development for two years. Matt has devoted now more than 40 employees from Automattic to core to help ship Gutenberg — a number I found staggering. There are dozens more fully volunteer workers on the project, and yet accessibility experts, especially around JavaScript-centric development, are still hard to find.

It certainly would’ve been easier and faster for Automattic to isolate editor development further to make it available within WordPress.com without it in core first, but Matt tells me he believes Gutenberg in core — sooner rather than later — unlocks a lot of Gutenberg-reliant integrations and feature development from plugin developers and other software makers.

I don’t know how much the community is itching to work on top of Gutenberg but I do trust that it will become an important part of building with and on top of WordPress.

Obviously, we all want all users to be able to user every feature of WordPress. But the standard being put on Gutenberg is not one that’s historically been applied to new features; I don’t mention that as an excuse, but rather to put it in perspective.

The classic editor will continue to a viable and accessible solution for years. There’s a message going into core to propose, “Users of assistive technology who experience usability issues with Gutenberg should use the Classic Editor.” 

One of the things I would personally like to see is, what would Gutenberg look like as a 100% accessibility ready editor? Is this out there? Is there a list of what would need to exist? Are there any web editors that are appropriately accounting for this experience — Squarespace, Wix, Medium, or others? I don’t know and am curious what a viable a11y-complete builder experience would look like.

I think it’s important to get above the trees to see the forest. Gutenberg is the vision from the project lead to take WordPress forward. Neither Matt or the hundreds of people working on that software take accessibility lightly. However, nothing is perfect nor just how we want it to be out of the gate. In fact, if we are 100% satisfied with a product upon release, we waited too long. In my view, Gutenberg has been very ambitious, and got very large in scope, and took too long. It’s time to get it out the door and start iterating.

One thing Matt mentioned was that in addition to the release, there will be point releases every two weeks to continue iterating, and fixing, issues. Gutenberg will not be a “set and forget” feature. That led us into the rest of our conversation around release schedules and development flows in WordPress, which I’ll save for another day.

Brian Krogsgard profile picture

Brian is a web developer in Birmingham, Alabama. He runs Post Status for WordPress professionals and Ledger Status for crypto investing enthusiasts.

Reading list: Accessibility

https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Accessibility Team Meeting Notes

The WordPress Accessibility Team meets every week on Friday at 16:00 UTC (11 am ET) in the #accessibility Slack channel in the WordPress team space. Here are the links to their meeting notes and the two Gutenberg Accessibility Status Reports.

9 Comments

“Matt tells me he believes Gutenberg in core — sooner rather than later — unlocks a lot of Gutenberg-reliant integrations and feature development”

But Isn’t that even _more_ reason to perform an accessibility audit *before* merging it into core? Once you open the floodgates, getting things fixed becomes 10X harder than having them correct and _then_ start bolting onto it.

Do you know _why_ a11y advocates have to be so vocal? Because more often than not, accessible features are promised and then *never* delivered. “But they can just use the Classic Editor!” which is a red flag for many that means accessibility in Gutenberg will continue to be an after thought, instead of a priority. And what happened to “All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA.”? Is that only apply when it doesn’t stand in the way of someone’s personal goals?

I don’t know if an accessible javascript-heavy editor exists, but then, as a community, let’s *lead* the way and build one instead of using it as an excuse!

I don’t agree. Not to be insensitive, but majority rules. Release Gutenberg now.

And you just verified my statement above about why a11y advocates have to be so vocal. 😉

There are plenty of things that are not done before Gutenberg is shipped with WordPress Core. A lot of people won’t be able to use the new editor from day one. Accessibility is just one aspect of the shortcomings of Gutenberg. Things will progress so much better, deeper and faster, when plugins & theme developers, and contributors have a core version with the new editor. As long as it’s ‘just’ a plugin, it signals it’s not yet worth bothering. It’s not real yet. If you want more and more people contribute, WordPress Core contributors need to be make the commitment and the decision to release first. The sooner the better.

I’ve used the UserWay.org script to help.

Also Matt how about dedicating a future update to Accessibility?

Possibly a good indicator of how accessible Gutenberg can be, is by looking at how accessible WP widgets are. I personally like to compare blocks for the editor to the widgets for the plugins; there are a few similarities at least in terms of how both blocks and widgets are used.

Then maybe move forward from there? So much more to learn about Gutenberg from both a developer and an end-user point of view.

Hi Lorna, thank you for contributing. It’s an interesting aspect considering that Phase 2 of Gutenberg development will deal with building blocks for widgets and also to use blocks in areas where widgets are used now.

[…] encore, un site dédié au projet explique clairement que ces compromis ont été faits sciemment. Pour résumer, on sacrifie une partie de l’accessibilité alors que WordPress représente […]