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.
The initial reactions to the announcement of the release schedule were negative, which is unfortunate. We have no desire to increase the fear, uncertainty, and doubt surrounding the release of Gutenberg. To that end, this article is intended to shed light on the issues the WordPress Accessibility Team sees as most critical to the success of Gutenberg at release.
We want to give some background on the Accessibility Team, the commitment WordPress has made to accessibility, and then dive into the issues in Gutenberg as of this writing. The issues addressed come from reviews of version 4.1.0 of the Gutenberg plug-in released on October 24th, 2018.
Who is the Accessibility Team
For anybody reading this post who’s not already deeply involved in the WordPress project, it’s important to give some background about the team structure in WordPress generally, and about ourselves specifically.
All teams in the WordPress project are made up of people who volunteer their time to focus on a specific issue affecting the project. We’re not employees of any specific company, and for the most part, our roles in the WordPress project are the results of our own choices, not because of an assignment from our employers. We can’t speak for every individual in the project – there are probably some people who work in a specific focus area because their employer wants to have an impact there.
On the Accessibility Team, we all have volunteered to participate on this team out of a desire to see WordPress provide a more accessible experience.
The team includes people who have 10-20 years of experience working professionally on web site accessibility and people who are completely new to the topic, but are motivated to learn.
The Accessibility Coding Standards for WordPress
In December 2015, members of the team met at the WordPress Community Summit in Philadelphia and proposed adding a commitment to accessibility as part of the core coding standards. These standards were published for public feedback in January 2016, and approved as part of the core standards in March 2016.
These guidelines are intended to set an expectation that all new code or significant updates embrace the standards in WCAG 2.0 at level AA.
It is important to acknowledge that it is possible to meet the standards in WCAG 2.0 AA without providing a reasonable user experience for users with disabilities or dependent on assistive technologies.
The Accessibility team – like any team in WordPress – has no specific authority over the project. Because we’re a small team of volunteers, we’ve been pragmatic in how we apply the guidelines. We have made tradeoffs in prioritization. Gutenberg is a place where we feel it is necessary to draw a line. The ability to author, edit, and publish posts is the primary purpose of WordPress.
Is Gutenberg an Accessibility Regression?
We want to acknowledge that the Gutenberg team has worked very hard, and have resolved many of the important accessibility issues raised by the Accessibility Team during development. They’ve built entirely new components to replace problematic interfaces like date pickers and color pickers. Keyboard accessibility has been built into the end-to-end testing processes. The accessibility work in this project is impressive.
Despite this dedication to accessibility in individual interactions, Gutenberg remains a system with significant challenges for users.
Gutenberg remains a problem because users cannot succeed by using only discrete components of the application. Even though each individual component is or will be accessible, the user needs to use the entire application.
Because the complexity of interaction with Gutenberg is an order of magnitude greater than in the classic editor, we believe that Gutenberg is less accessible than the existing classic editor, though it offers many great features that are not available in the current editor.
Issues with Gutenberg
The specific issues with Gutenberg are reasonably well represented by the issues published under the Accessibility label in Github. What is not so easily identified from a review of these issues is the systematic nature of some of the accessibility problems.
While we can’t address all issues or types of issues in this article, we can address a handful of the problems with Gutenberg that have a profound impact on users of assistive technology and need to be addressed systematically.
Cognitive Load & Complexity
At the very top of our list of concerns, we feel the overall experience for users with accessibility needs is an accessibility regression. This is due to the complexity of the interface and unexpected, non-native, interaction with many components. These non-native interactions impose a steep learning curve on users of assistive technology as their normal modes of interaction may not work as expected.
Contributing to the challenges of locating and remembering the location of controls, we find visual design considerations have been given priority over information architecture. The order and logical grouping of the user interface controls should be paramount for all users. Instead controls are grouped in a way which may seem arbitrary. In addition to the lack of a systematic organization of the controls, they are continuously appearing and disappearing.
Constantly shifting controls are confusing for screen reader users in particular, as they don’t get the visual affordance to know when something is no longer available in the interface. The classic editing experience was linear, contained within a single block. The controls were in a single fixed location on the page. This provides a predictability that is no longer present in the interface.
This issue has been regularly reported by users of screen readers, but has not been effectively resolved. Rather than addressing the specific issue – buttons that appear and disappear in an unpredictable fashion – new tools have been added to provide another alternative mode to navigate between blocks. (See issue 10545, “Adds the block hierarchy navigation menu…”).
This tool is potentially useful, but it does not serve to simplify or streamline navigation.
Inconsistent User Interface Behavior
The cognitive load in Gutenberg is heavily influenced by inconsistent behaviors within the user interface. An issue reported in August 2018 reflects the experience of a JAWS user attempting to explore Gutenberg (and has not yet been handled). This user cited random changes of focus (which is likely related to keyboard navigation changes depending on the type of block, whether or not that block has content, and whether you’re navigating forwards from a block or backwards from a block.
Without any visual context clues about these controls, the focus would appear to be arbitrarily changed.
Additionally, some toolbar controls behave differently from others. This contributes to the impression of focus moving arbitrarily, since a user cannot readily predict what will happen on triggering these controls.
The combination of behaviors that are self-consistent, but appear inconsistent when you are not clear of the rules governing the changes (such as the block navigation) and behaviors that are not self-consistent (like toolbar buttons) creates a major usability problem.
Accessibility Anti-Patterns
While the efforts towards accessibility have been significant, there has been a strong dependence on methods we consider to be anti-patterns. First among these is a heavy use of ARIA attributes. ARIA, while sometimes necessary, should be considered only as a final option when no native HTML interactions are available.
This reflects a problem in the design process: beginning with custom controls (such as the “switch toggle”), then attempting to make them accessible rather than beginning with standard controls and making a functional interface.
Other anti-patterns incorporated in the design that should never have been under consideration include:
- Placeholders replacing labels
- Icon-only controls (buttons with no visible text label)
- The Switch Toggle and other custom interface elements
Incorporating best practice accessibility into design at the beginning can help avoid these problems.
Keyboard Shortcuts
One of the only practical ways to ease the complex navigation between sections of the application from the keyboard is to introduce a variety of keyboard shortcuts. These can be helpful, but they create their own new problems.
The only way to totally avoid conflicts across browsers, assistive technology, and operating systems is to allow a mechanism for user to re-map and customize shortcuts. This has been an unresolved open issue since October 2017.
Keyboard shortcuts have inherent challenges in discoverability, but they do provide a learnable system to improve the user experience. Providing a method to customize these shortcuts would also act as a method to allow users to learn and reference the shortcuts from within their editing environment.
As it stands, Gutenberg provides these keyboard shortcuts for people who depend on the keyboard, but does not fairly ensure that they can be functional.
Keyboard Navigation
The ability to navigate through a document is a key element of the editing process. In the current iteration of Gutenberg, this is a significant challenge.
Keyboard navigation through blocks is possible, but it requires a vast number of keyboard actions. There is a committed proposal from the accessibility release lead that’s related to this topic, but it’s unclear whether it truly resolves the issue.
The introduction of a ‘block hierarchy navigation menu‘ allows users to see a list of all blocks in a post and move their focus to a given block. This is certainly related, but it does not resolve several key concerns:
- Keyboard navigation from block to block requires easily 10 or more tab stops, and the exact number of stops is highly variable.
- Keyboard navigation by tab
- Arrow key navigation between blocks can have some disconcerting behavior with screen readers. (In NVDA with Firefox it works reasonably well, but in NVDA with Chrome the reading cursor reads from the previous block though editing focus moves to the next block.)
- Arrow key navigation sometimes moves directly between blocks and sometimes includes button controls, depending on where focus is currently set.
- Moving between your current block and block settings is very difficult. You can use the landmark navigation keyboard shortcut to jump to the settings, but this requires multiple usages of a multi-key combination to get to the correct settings, the discovery of the settings in that panel, the discovery of the link to return to your selected block, then tabbing through all controls attached to the block before you reach the block content to return to editing. In a test to change the font size in a paragraph block, the following keyboard sequence was required (starting with the cursor in the block text.)
- Press
Ctrl + ` four times to locate the block settings.
- Press
tab five times to reach the font size selector.Discover the usage of the non-standard selector dropdown (normal selector: arrow key down to desired value, press enter to select, tab through rest of document. This selector: Enter to expand dropdown, tab key to choose desired value, Enter to select that value, esc key twice to exit selector.)
- Press
tab six times to locate skip link back to selected block.
- Press
Enter to activate the selected block.
- Press
tab thirteen times to reach the editable text of the block.
- The above navigation scheme required 34 separate keyboard stops in order to change the font size of the selected text and return to the previous position, and is aided in efficiency by the tester’s prior knowledge of how to navigate the process. (Tested in Chrome and in Firefox using NVDA.)
We want to be clear that the above example is not comparable to the options available in the classic editor – there is no mechanism for increasing the font size of a paragraph in the existing editor. However, given the above requirements, there may as well not be one in Gutenberg. Changing the font size is just one of many editing features that are exclusively available from the block settings sidebar.
While this demonstrates an accessible process, when compounded into an interaction system that depends on dozens or hundreds of similar interactions, the end result poses significant burdens on the user.
One limitation of the block hierarchy navigation menu is in understanding the value of the represented blocks. What a user might want to do is edit the paragraph that starts with “The quick brown fox…”. What they are presented with is a list of enumerated block types. What value does “Paragraph 5 of 6” provide the user? Reaching a specific paragraph easily is only valuable if you have context for what you will be doing, and that information is not provided here.
Who is affected?
The accessibility issues in Gutenberg only affect the authoring and editing of content in WordPress. We don’t have any significant concerns about the code produced by Gutenberg – in fact, some of the tools in Gutenberg will hopefully improve the accessibility of produced code on the front-end.
All authors and editors will be affected by these changes. Administrators responsible for deciding whether Gutenberg is appropriate for their sites need to be informed that it may pose unacceptable barriers for their authors.
There is a long history of people with disabilities losing their jobs because they were provided with new ways of doing the job that imposed barriers for them. WordPress should not cause anybody to lose employment.
To this end, the accessibility team proposed a clearly discoverable notice in the WordPress 5.0 release to inform administrators of the risks in allowing Gutenberg for users of assistive technology and provide instructions on installing the Classic Editor plug-in. At this time, that proposal has been closed with the ambiguous note “5.0 will point users to the classic editor plugin if they need it.” It is not clear what this means or how it might be implemented.
In Conclusion
The main accessibility issues in Gutenberg stem from design issues, whether those are about the organization of controls, large architectural decisions, or specific small interface elements. We see WordPress as an inclusive community that embraces much of what is wonderful in the open source community, and has a history of providing a publishing platform that empowers all users to publish their content.
Gutenberg is the way of the future in WordPress, but the direction it has taken so far has been worrying. We do not want to miss the opportunity to build a modern and inclusive application for WordPress, but in order to achieve that goal, accessibility needs to incorporated in all design processes in the project.
These problems are solvable. Retrofitting accessibility is not an effective process. It is costly in terms of time and resources.
We hope for a truly inclusive end product. The progress made within Gutenberg is not trivial – there have been many very difficult problems to solve. Solving these larger design issues will give us a positive path towards the equal inclusion of all.
In the short term, we hope to resolve all accessibility issues that are true barriers to the use of Gutenberg. In the long term, we hope to improve the integration of accessibility into all future WordPress design processes.
The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.
