Gutenberg and accessibility: personal thoughts and perspectives

There’s been some great (and not so great) discussion on WordPress’ project Gutenberg – the new WordPress editor experience that is being developed. I’m not going to recap everything here in this post. But before I share my own personal thoughts and perspectives on Gutenberg, I do want to share some links to some great posts on the current state (and issues) of Gutenberg’s accessibility.

—

So now my personal thoughts and perspectives (that’s why you paid good money to hear this, right? :-) ).

Most of Gutenberg’s accessibility issues stem from decisions made early on in the design and development process. Gutenberg’s focus has been primarily about a slick modern visual UX experience using modern JavaScript. Unfortunately this meant (and means) that other important aspects were not focused on as strongly. Let me make it abundantly clear that I do not believe Gutenberg designers and developers ignored accessibility or downplayed it. It just wasn’t the major focus.

The WordPress a11y (accessibility) team is a group of volunteers who meet weekly to discuss WordPress accessibility issues and how to resolve them. Note the keyword here is volunteers. Most are not WordPress core contributors or developers. We don’t really provide pull requests and patches as – for many of the volunteers – that’s just not our strength or skill set. Gutenberg further exacerbates this by adopting a modern javascript framework with all the tooling and workflows necessary for that – which makes for an interesting barrier to entry. Aside: I think the javascript focus will be good over the long run, but right now it’s a major pain point that cuts into what and how volunteers can contribute. Anyway, as Gutenberg became the focus for WordPress, the a11y team did it’s best to provide suggestions on how to resolve the many accessibility issues we discovered in personal and actual user testing. We tested, we filed issues, we participated in discussions. But we kept feeling like accessibility was not being appropriately balanced with the main Gutenberg focus. It didn’t help when updates broke fixed accessibility issues (regressions) and new features seemed to highlight the lack of basic accessibility testing prior to committing. It was disheartening. Things really came to a head with the 4.9.9 “nope-just-kidding” release. We were told 4.9.9 was being planned as a typical WordPress release and one of it’s focus’ would be addressing accessibility issues before Gutenberg landed. The team was pretty excited and we started a major review of the open accessibility tickets and divided them up among folks with time/capability to provide feedback on them. After a couple of weeks of this flurry of excited activity, we then heard that 4.9.9 release would now only focus on some PHP update work. The communication about this was less than ideal and left many of the a11y team shocked. I believe this was the tipping point. Soon thereafter Rian left, and others of us stepped back from helping out. Why should we volunteer and help out when it seems like our time and efforts were being wasted and unappreciated? Fortunately it looks like the team is rebounding after taking stock of the situation and having a good and productive team discussion.

So here’s my final thoughts and opinions on Gutenberg and accessibility

I don’t think Gutenberg ignored accessibility but it wasn’t a major focus and unfortunately this shows in the current product.
Accessibility needs to be baked in from the start for best effect – Gutenberg unfortunately shows a tendency to try and bolt on accessibility after the fact, which never works as well in any experience I’ve had.
Design expresses intent and if accessibility isn’t a major focus of the deign’s intent… well then, no amount of bolting on can hide or fix that. Again, not a ding on the Gutenberg designers but rather a ding on the project’s priorities and focus that I don’t think properly attached enough weight on accessibility.
As it stands right now, Gutenberg probably needs at least 2-3 more months of strong accessibility and usability focused work to reach what I feel is a safe and acceptable “release-to-the-world” product level. I do have to give the team mad props for how much they’ve accomplished in such a short amount of time though!
It is sad that the WordPress project decided against doing an accessibility audit on Gutenberg – I think this would have provided some great actionable feedback at a holistic level that the a11y team just doesn’t have time or bandwidth to provide.
Going forward I would recommend that the WordPress project consider having releases led by a designer, developer and accessibility lead to ensure that all new features strike an appropriate balance between good design, modern development best practices, and accessibility.
A special thanks to the WordPress a11y team of volunteers – you’re the best!