Caution Advised for 508-Compliant sites and WordPress 5.0
If you are an organization that is legally required to be Section 508 compliant, you are going to have to make a decision by November 19th. That is the day that WordPress 5.0, also known as Gutenberg, is scheduled to launch.
The main criteria that will determine how your organization should proceed are two-fold. The first is simply whether or not you have a legal responsibility to be Section 508-compliant. The second is whether or not your team has tested your theme and plugins combination for Gutenberg compatibility.
Depending on how you answered those questions, we’ll go over the various courses of action available to you and your staff below.
If you have not yet done any Gutenberg compatibility testing, please make it a priority for your team to do so in the immediate future. Remember to do so only on a testing or staging site, not your live site.
But first, let’s take a quick look at where WordPress 5.0 and accessibility concerns currently stand, how we got there and how we will all move forward.
Where WordPress 5.0 and Accessibility Currently Stand
WP A11y Team Lead Change
On October 9, 2018, Rian Rietveld resigned as the WordPress accessibility team lead. She had been with the WordPress’ accessibility team for several years and published her thoughts on why she was leaving. The new WordPress a11y team lead, Matthew MacPherson, is already in place and doing his best to address accessibility concerns in WordPress 5.0.
Here are the four main problems Rian listed that the WordPress a11y team ran into when they were evaluating Gutenberg, submitting tickets and proposing solutions:
- The codebase of Gutenberg was difficult for the a11y team because none of them are skilled React developers. What they could do is test, report what’s wrong and hope a developer would pick it up.
- Conversely, there was no React developer in the WordPress community with accessibility experience, and no React accessibility experts from outside the community willing to work on the issues for free.
- Functionality that was tested, improved and then approved, changed in a later stage, breaking the a11y improvements again.
- New functionality was not keyboard tested before implementation (e.g. the date picker).
While several accessibility issues have been addressed, many others remain unresolved and will still be unresolved by the time of the official planned 5.0 release date (November 19).
Gutenberg Accessibility Review Proposals
Upon taking over the reins of the WP a11y team, MacPherson proposed an independent audit of Gutenberg relating to accessibility issues. After soliciting proposals however, he had to cancel the audit because he was unaware that he didn’t have the ability to authorize such an outside audit. As of our date of publication, there is no accessibility audit planned from within Automattic (WordPress’ parent company).
On October 24, WPCampus, an organization representing the interests of the higher education community such as universities and others, announced their own RFP (request for proposals) for an accessibility audit of the WordPress Gutenberg editor.
As WPCampus notes:
“Our organization is sensitive to the legal requirements set by Section 508 of the Rehabilitation Act. The recent 508 refresh brought these requirements in line with WCAG 2.0 level AA, an industry standard that helps ensure accessibility.
While the WordPress accessibility coding standards require new code to meet WCAG 2.0 AA, the new editor has not received a full accessibility audit. Lacking such an audit, the overall accessibility of Gutenberg is unclear. This makes it difficult for colleges and universities to determine the best course of action once WordPress 5.0 is released with Gutenberg as the default editor.”
WPTavern has a very informative article on the WP a11y lead change and WPCampus’ a11y audit proposal if you’re interested in learning more.
WPCampus’ RFP and funding for an accessibility audit is to be applauded, but the results from such an audit will not be presented until mid-January. That means it could be at least three months from now until accessibility concerns with the new editor are addressed.
So, what should the numerous organizations that are legally required to be compliant with Section 508 do when WordPress 5.0 is officially released later this month (barring any unforeseen delays)?
How Should Your Organization Proceed When Gutenberg Is Released?
When WordPress 5.0 is released in the coming weeks, your 508-compliant organization’s course of action should be determined by which category below best describes your situation. If you are not required to be 508-compliant, or are voluntarily compliant, you will have much more leeway in your decision-making process. Please bear in mind that the “testing” referred to below does not include accessibility testing, but only whether or not your current theme and plugins combination has been tested for compatibility with Gutenberg.
Which of the following statements best describes your current situation?
- We have done testing to see if our WordPress theme and plugin combinations work with Gutenberg. They do.
- We have done testing to see if our WordPress theme and plugin combinations work with Gutenberg. They don’t.
- We have not done testing to see if our WordPress theme and plugin combinations work with Gutenberg.
- We are running an older version of WordPress (pre-v.4.9)
For all cases except D, the simplest blanket solution is to install either the Classic Editor plugin or the Disable Gutenberg plugin and activate it. Then you can install the 5.0 Gutenberg release when it comes out and you will bypass the Gutenberg editor. You can even install the Classic Editor plugin from right inside your WordPress site’s dashboard, on the right side of the Gutenberg “nag,” as shown below:
As of the last WordPress update, the Gutenberg “nag” shows up in your dashboard and allows you to try the Gutenberg editor while it’s still a plugin, and also allows you to install the Classic Editor plugin.
But there are also case-specific options available to you.
If statement A best describes your situation (we have tested our WordPress theme and plugins with Gutenberg, and nothing breaks) and you have an experienced developer or team in place who can audit accessibility concerns, you can run Gutenberg on a staging site and verify and/or attempt to address any accessibility concerns you find specific for your site. If you are using the Disable Gutenberg plugin, you have the added ability to enable Gutenberg just for the post types, theme templates, etc., which you have successfully determined are accessibility-ready and will keep you 508-compliant.
If statements B or C best describes your current situation (Gutenberg does not work with our WordPress theme and plugin combination, OR we have not tested it yet), the recommended course of action when WordPress 5.0 is released is to install and activate either the Classic Editor or Disable Gutenberg plugin before installing WordPress 5.0, Gutenberg. If Gutenberg is already breaking your site (a relatively rare occurrence) or you haven’t even tested it yet, it is not worth risking falling out of 508-compliance, so simply choose to use the plugin and bypass it.
In the meantime, start (or continue) testing Gutenberg on a staging or test site. If you have a custom theme and Gutenberg breaks your testing site, ask your developer to make any necessary modifications. Zac Gordon has a Gutenberg course for developers and has shared a short video on making your theme Gutenberg-compatible. There are also plugins being developed which will help with Gutenberg theme support.
An alternate, but not necessarily recommended, course of action being taken by some is to stay on the 4.9 branch of WordPress until all accessibility concerns have been addressed.
If statement D best describes your current situation (those who are running older versions of WordPress), you may not be in a position to skip ahead to 5.0 when it is released. While we certainly do not recommend that anyone run an older version of WordPress, you are not alone in doing so. Many sites are using older themes and plugins that are not yet compatible with the latest version, while for many others it is simply a case of no one in their organization being aware that their site is running an older version of the software. A 2017 study by Hacker Target found that over 40% of the top 100,000 WordPress websites were using older versions of WordPress.
The danger in sticking with WordPress 4.9.x or lower is that each update of the WordPress core addresses and fixes bugs and reported issues. By keeping your website running on an older version of WordPress, you can make your website more vulnerable to hacks, malware and outside mischief should someone decide to exploit your site’s weaknesses. Although there are many sites out there who have been running older versions of WordPress for a while, sooner or later these kinds of things can catch up to you, so it is best to try and use as current a version of WordPress as you can on your site.
Whether you need to disable Gutenberg because of accessibility concerns (508-compliant sites), because it doesn’t play well with your theme and plugin combination, or simply because your writers and content uploaders haven’t yet adjusted to the experience of creating and publishing posts with the Gutenberg editor, there are several methods to bypass WordPress’ 5.0 Gutenberg editor.
One of the best posts on the subject is Jeff Starr’s excellent article How To Disable Gutenberg; Complete Guide. Starr, author of several WordPress books and plugins, including Digging Into WordPress, is also the author of the Disable Gutenberg plugin.
In his article, which was updated on October 28 of this year, Starr goes over several methods of disabling the new editor. The article is geared towards developers and site administrators who may have the responsibility of overseeing numerous websites and may not have the time or resources to properly vet and set up the new editor in all of their client sites at once. His solution: Disable Gutenberg until you are ready for it.
Disabling Gutenberg Via A Plugin
Obviously, the lead-off suggestion is to disable Gutenberg by using a plugin, as mentioned above. The Classic Editor plugin has a very simple interface and limited settings:
[caption id=”attachment_13747" align=”aligncenter” width=”600"]
The Classic Editor plugin settings screen. You can select which option in the blue area that you wish the plugin to follow.[/caption]
The other main plugin used to bypass Gutenberg is the Disable Gutenberg plugin. Although not as popular as the Classic Editor plugin, it appears to be much more robust than its counterpart, providing the user with many more options and actions, such as:
- Disable Gutenberg completely (all post types)
- Disable Gutenberg for any post type
- Disable Gutenberg for any user role
- Disable Gutenberg for any theme template
- Disable Gutenberg for any post/page IDs
The Disable Gutenberg plugin’s settings page. If you uncheck the Complete Disable box at the top, you are presented with more selective options, as shown below:
The options available with the Disable Gutenberg plugin once you have unchecked the Complete Disable checkbox in its settings panel. Here, you can selectively apply where the Gutenberg editor can be used within your site.
In addition, the plugin even allows you to hide the plugin menu item so that an administrator cannot accidentally turn it off.
The Classic Editor plugin is still the much more popular option, with over half a million in use. But you may find that the available options in the Disable Gutenberg plugin are more in line with your needs.
Disabling Gutenberg Via Code
Your developer can also disable Gutenberg by code. According to Starr, the code currently required as of publication to completely disable Gutenberg is:
Disclaimer: If your organization wishes to pursue this route of disabling Gutenberg by code, please ensure that this change is only implemented by someone who knows how to work with code/PHP.
For those interested in diving deeper into the subject, check out the article for more examples of code for:
- Disabling older versions of Gutenberg
- Disabling Gutenberg for custom post types
- Disabling for meta boxes
- and more…
Going Forward With Gutenberg and Accessibility
Hopefully, this article has provided you with food for thought on how your 508-compliant organization can best proceed once Gutenberg is released. It is very important that those who are legally required to adhere to these standards keep themselves informed of the latest developments, and to be proactive by testing and planning your course of action.
As we await the final countdown for WordPress 5.0, decide which approach is best for your team and have a plan in place to enact it.
After 5.0 has been released, here are some resources to keep your staff appraised of the latest developments with the Gutenberg editor as the accessibility audits, proposed changes, track updates and improvements continue to bring Gutenberg closer to a11y-ready over the next few months:
- The WP A11y team
- Gutenberg development hub
- WPCampus and the state of their audit
- Visiting the Classic Editor and Disable Gutenberg plugins’ home pages and support forums
- Workshop testing for web accessibility
- The support forum for the Gutenberg plugin. Even after Gutenberg becomes part of core and doesn’t need to be a plugin any more, this forum will continue to be a good place to find out what kinds of problems and solutions people ran across with Gutenberg.
- Make.wordpress’ weekly What’s New In Gutenberg blog
- Make.wordpress.org’s accessibility testing
- Here at the AmDee blog
- An a11y collection of js modules and tools for devs
As a final note, the WordPress Accessibility team has shared that they have selected new team reps and are working on a post to help define issues currently seen in the block editor, which they hope to share in the coming weeks.
Additionally, if you need help with your 508-compliant organization’s website, you can also call us here at AmDee for a consult.