Announcements

Gutenberg Accessibility Audit Response

By Brian DeConinck

NC State University’s IT Accessibility Office and OIT Design & Web Services have reviewed the results of the WPCampus Gutenberg Accessibility Audit that was published on May 1, 2019. Many of our campus websites utilize WordPress. For that reason, it is imperative that users are aware of current accessibility barriers in the new WordPress block editor, also referred to as Gutenberg.

Please review the recommendations below, and share this post with your web support team if applicable.

Background

The WordPress Accessibility Coding Standards require that all new and updated code added to the WordPress application meet WCAG 2.0 AA guidelines. Despite this requirement, the Gutenberg block editor was incorporated into WordPress and released in WordPress 5.0 without accessibility auditing to verify that it meets these guidelines.

Prior to the release of the new editor, WPCampus commissioned an independent accessibility audit. This effort was led by web staff at higher education institutions (including a member of NC State’s OIT Design & Web Services team). The goal of the audit was to obtain an impartial assessment of any potential accessibility barriers introduced by the new editing experience.

This audit, conducted by Tenon LLC, revealed “significant and pervasive accessibility problems.” Tenon provided a 329-page technical report to WPCampus, including remediation recommendations and code examples. WPCampus made these findings public and provided them to the WordPress project leadership.

Since the release of the audit, developers working on the WordPress project have already made significant progress toward resolving the issues identified by Tenon. We will be monitoring future WordPress releases, and we will update our recommendations to reflect progress as it is made.

(On a personal note: I’m super proud of my part in this. WordPress powers about a third of the web, and this project will end up helping a lot of people worldwide.)

Key takeaways

The block editor presents barriers for creating accessible content and accessibility barriers in the authoring tool itself. Because of these barriers, we have detailed our recommendations for using the editor:

Classic Editor plugin options and guidelines

Although the block editor is now the default WordPress editing experience, the pre-Gutenberg “classic editor” is available via the Classic Editor plugin. This plugin will be maintained by the WordPress project until at least 2022.

The Classic Editor plugin has multiple configuration options:

  • The block editor can be completely hidden from all users. When configured this way, users will see only the classic editor.
  • The block editor and the classic editor are both available to users. When configured this way, additional options are available:
    • Administrators may set the default editor to be either the block editor or the classic editor.
    • Individual users may set their preferred editor, making their choice the default for the content they create.

For simple content (text and images only), the editors may be used interchangeably. If more complex content is created using the block editor (eg. column layouts, custom blocks), some data may be lost if that content is subsequently edited using the classic editor.

For this reason, we do not recommended that multiple people editing the same website use different default editors—even though this is possible with the Classic Editor plugin. All editors of a site should use the same editor for all content.

Recommendations for site administrators

Site administrators should be aware of the potential impact of accessibility barriers for content creators with low vision, that utilize assistive technology, or who only use a keyboard. If these individuals are users authoring content on your website, you should not adopt the Gutenberg block editor at this time.

Similarly, since many of the current accessibility output errors can be remedied via using the HTML editor, we do not recommend the use of the block editor for websites whose content creators are not comfortable editing HTML.

Most WordPress user groups on campus are aware of their own skill level and abilities. These groups can make an educated decision based on our recommendations whether or not to use the Gutenberg block editor. For users groups that are larger and change frequently, like student organizations or blog sites that are shared by many editors, we do not recommend the use of Gutenberg at this point in time.

Recommendations for authoring accessible content in the block editor

Some of the accessibility barriers (detailed in the full Gutenberg Technical Report) do not just impact Gutenberg authors, but the ability to render accessible content. We advise being very intentional with your use of the block editor (if you should choose to use it). Note that some of the recommendations below may be applicable to both the block editor and the classic editor.

We recommend:

  • Provide the NC State Accessibility link in the footer of your website so that individuals know where they can go to put in any accessibility feedback that they may have.
  • Do not use the Video block as currently, you cannot add captions in the visual editor.
  • If adding video or audio blocks, do not set the media to autoplay.
  • Give each post a unique page title.
  • Only create data tables with Gutenberg in the HTML editor so you can manually add table headers, or use other legacy table-building plugins (eg. TablePress). Most of these plugins will continue to work with the new editor.
  • Ignore the errors presented in the HTML editor and continue to add table semantics.
  • Test your websites by enlarging them to 150% and 200% and ensure that all of your content is still available, in the appropriate tab order and content does not overlap
  • If users are creating content in multiple languages, they should manually add a ‘lang’ or ‘dir’ attribute in the HTML editor. If content is in the default language of the website (at NC State, typically English), then no action is required.

Update notes

To track progress toward resolving accessibility issues in the block editor, Tenon LLC has created a collection issues in GitHub. Campus web developers and site administrators may find it useful to track these issues.

Questions or comments

Please do not hesitate to contact either team if you have questions, comments, or concerns.