@alleyco
Gutenpocalypse Never:
How to Build Accessible Sites in WordPress Using Gutenberg
Kevin Fodness, PhD
Director of Software Development
Alley
@alleyco
About Me
@alleyco
Roadmap
@alleyco
Accessibility Issues at Gutenberg Launch
(December 2018)
01
@alleyco
Gutenberg Timeline
@alleyco
Run-Up to Launch
@alleyco
“On October 3rd, the schedule for WordPress 5.0 was proposed. Prior to this, the accessibility team had not been made aware of a release time frame, and had no reason to believe WordPress 5.0 and the Gutenberg editor were under time pressure. The schedule proposed a release date of November 19th – 6 weeks from the announcement date.”
— Joe Dolson
https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/
@alleyco
“The codebase of Gutenberg is difficult for all of us, because no one in the wpa11y team is a skilled React developer. So it was hard to implement changes and write PRs ourselves. What we could do is test, tell what’s wrong and what it should be and hope a developer would pick it up.”
— Rian Rietveld
https://rianrietveld.com/2018/10/i-have-resigned-the-wordpress-accessibility-team/
@alleyco
“The results indicated so many accessibility issues that most testers refused to look at Gutenberg again.”
— Rian Rietveld
https://rianrietveld.com/2018/10/i-have-resigned-the-wordpress-accessibility-team/
@alleyco
Key Problems
@alleyco
Inadequate accessibility knowledge
among React developers
+
Inadequate React knowledge
among accessibility team members
@alleyco
Release date held firm despite
not meeting accessibility commitments
@alleyco
Accessibility focus on
individual blocks and components
rather than
the entire system
@alleyco
WPCampus / Tenon Audit
@alleyco
“For the most part, the markup generated from the Gutenberg editor is clean, semantically correct and accessible.”
https://documents.wpcampus.org/gutenberg/audit/Gutenberg_Executive_Summary.pdf
@alleyco
“Based on the data shown in the table above, Gutenberg has an average of 5.6 issues per component. This places Gutenberg in the top 30% worst performing products tested by this same team of testers.”
https://documents.wpcampus.org/gutenberg/audit/Gutenberg_Executive_Summary.pdf
@alleyco
“Overall, Gutenberg’s user experience
is consistently poor”
https://documents.wpcampus.org/gutenberg/audit/Gutenberg_Executive_Summary.pdf
@alleyco
“Gutenberg has significant and pervasive accessibility problems, the likes of which amount to a step backwards for users with disabilities over the legacy editor.”
https://documents.wpcampus.org/gutenberg/audit/Gutenberg_Executive_Summary.pdf
@alleyco
“Please use this report as what it is intended to be: constructive feedback in support of the WordPress project. We hope this report generates discussion about accessibility, excitement about inclusive design, and action toward improving the editing experience.”
https://www.wpcampus.org/blog/2019/05/gutenberg-audit-results/
@alleyco
Current State of Gutenberg Accessibility
02
@alleyco
5 WordPress releases
since Tenon audit
(5.0 => 5.5)
@alleyco
84% of a11y issues in Gutenberg repo closed
(1136 closed, 217 open)
@alleyco
74% of a11y issues from Tenon audit closed
(62 closed, 22 open)
@alleyco
Accessibility is a
continued priority for the Gutenberg team
@alleyco
It’s not perfect.
@alleyco
...but it’s much better
than it was at launch.
@alleyco
I’m not a lawyer.
@alleyco
Using Accessibility Controls in Default Blocks
03
@alleyco
Default blocks are typically very accessible
@alleyco
Use default blocks whenever possible
@alleyco
Use Block Controls in the Sidebar
@alleyco
Image Block: Use Captions
@alleyco
Image Block: Add Appropriate Alt Text
@alleyco
Audio & Video Blocks: Use Captions
@alleyco
Audio & Video Blocks: Use the Defaults
@alleyco
Headings: Use Info Panel to Verify Hierarchy
@alleyco
Tables: Use Header, Caption, Footer (if necessary)
@alleyco
Tables: Use Header, Caption, Footer (if necessary)
@alleyco
Links: Don’t Open in a New Tab!
@alleyco
Follow a11y best practices!
@alleyco
Building Accessible Custom Blocks
04
@alleyco
Create all custom blocks as “dynamic blocks”
@alleyco
Follow general a11y best practices
in the editor + front-end
@alleyco
Use built-in Gutenberg components
(don’t roll your own)
@alleyco
Leverage InnerBlocks for repeatable content
@alleyco
Don’t use metaboxes
(use Document panel SlotFills)
@alleyco
Don’t let editors make a11y mistakes
(e.g., color contrast)
@alleyco
Contribute to the project on GitHub!
@alleyco
Thank You
@alleyco