Major accessibility improvements are the headline feature of this week’s Gutenberg plugin release. Version 6.3 introduces new Navigation and Editor modes to address long-standing problems navigating the block UI with a screen reader. The editor is now loaded in Navigation mode by default. Riad Benguella described it as “an important milestone in terms of accessibility of the editor” and explained how it works:
It allows you to move from block to block using a single Tab press. You can also use the arrow keys to navigate between blocks. Once you reach the block you want to edit, you can enter the Edit Mode by hitting the Enter key. The Escape key allows you to move back to the Navigation Mode.
These modes are still early in their development and will require more testing.
At WordCamp US 2018 in Nashville, Accessibility Team contributor Amanda Rush gave me a demonstration of what it is like to navigate Gutenberg with a screen reader. Using the editor was painfully difficult for even the simplest tasks, such as setting a title and writing paragraph content.
Since that time, the Gutenberg and Accessibility teams have made great strides towards improving this experience. The new interaction flow in the Navigation mode is one example of their progress. The teams have also worked together to tackle a collection of 84 issues that Tenon created on GitHub in May, based on the findings in WPCampus’ Gutenberg Accessibility Audit. To date, 54 of those issues, many of which were related to screen reader accessibility, have been resolved and marked as closed.
Other notable updates in Gutenberg 6.3 include support for text alignments in table block columns, border color support for the separator block, and improvements to the BlockPreview component, which allow developers to preview blocks in any context. Check out the release post for the full list of all the changes in 6.3.
WordPress’ accessibility team is evaluating the possibility of organizing a virtual Global Accessibility Day, similar to the Polyglots’ Global Translation Day. This marathon-style contributor event has proven to be valuable for the Polyglots in terms of recruiting, onboarding, and fueling progress on translation projects.
Accessibility contributors proposed the idea at a meeting two weeks ago after discussing the team’s desire to have more representation at WordCamp contributor days. WordCamp Europe 2019 had a strong contingency of accessibility contributors, but being present on the ground in Berlin was not an option for the vast majority of the team.
“I heard different people saying that this Contributor Day was extremely useful, because they had the opportunity to talk in person and exchange ideas with a lot of other people,” Stefano Minoia said. “This is really good: if we want to push forward a project like WordPress, it’s extremely important to have the opportunity of working together at least once a year in person.”
Due to the relatively small size of the team and the expense associated with traveling to larger WordCamps, accessibility contributors do not often have the opportunity for in-person collaboration. A remote contributor day focused on accessibility was proposed as an alternative.
“We’re a small group with very little sponsorship,” Joe Dolson said during the initial discussion. “I don’t go to most WordCamps anymore, because the time and expense is just too great for me. I’ll probably go to my local WordCamp only, this year, if I have the time.”
Due to the nature of the work, Dolson anticipates the team may face some challenges in working around some of the constraints of collaborating through a virtual event.
“There are some tasks that work really well as remote contributor days; others are harder,” he said. “I’ve personally found it difficult to do accessibility contributor sharing remotely.”
A virtual contributor day could be helpful for some basic things like teaching new contributors how to use Trac, updating the handbook and documentation, and organizing sprints for jumpstarting larger tasks. There is no shortage of accessibility projects to work on, with the new block directory in the admin slated for this year, some major changes needed to improve navigation to Gutenberg’s advanced settings block sidebar, and more general Gutenberg issues.
One development that is working in the team’s favor is that Slack has improved the screen reader experience in the most recent update. Using threads was previously discouraged during accessibility team discussions due to their lack of navigability. Keyboard accessibility for getting around Slack should now be more streamlined than previous versions. This should help to improve remote collaboration for the accessibility team. Users can press CMD + ? to launch the list of available keyboard shortcuts in Slack.
As a first step towards organizing a 24-hour virtual event, WordPress’ accessibility team is working to put together a team of 10 or more people to lead the effort. Organizers will then determine the scope of the project, define the goals of the event, set a timeline, and begin the call for speakers and local meetups.
“The scope of the day can change based on the team,” Dolson said. “If we can’t do 24 hours, that’s fine, but the team has to come first.”
Anyone interested to help organize the event can sign up on the project’s public spreadsheet.
The WordPress Theme Review Team (TRT) met today and agreed to put new accessibility requirements in place for themes hosted in the official directory. These include some of the items that are required for theme authors who want to add the accessibility-ready tag. A handful of these requirements will soon be added to the standard requirements for all themes. The initial focus will be on items that do not have a major visible impact on a theme’s design, as the team anticipates some pushback from designers.
“We’ve long made the argument that WCAG can’t easily be applied to a theme which has no content; I don’t think we want to break that,” Accessibility team member Joe Dolson said. “For the purpose of theme testing, I think it’s still better to target a customized set of criteria that are content-independent. But if we can incorporate the first four items in the guidelines, I’d be super happy. The rest of the criteria, while important, are harder to assess and implement, and have greater impact on design.”
The Theme Review Team has agreed to start gradually rolling out new accessibility guidelines every other month while educating developers to help them get on board. The first requirement will be Skip Links, followed by the other three that are outlined in the Theme Review Handbook:
- Skip Links
Themes must include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links may be positioned off screen initially but must be available to screen reader users and must be visible on focus for sighted keyboard navigators.
- Keyboard Navigation
Theme authors must provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. All controls and links must be reachable using the keyboard.
All theme features that behave as buttons or links must use button, input, or a elements, to ensure native keyboard accessibility and interaction with screen reader accessibility APIs.
All controls must also have machine-readable text to indicate the nature of the control.
- Form Labeling
Comment forms must have appropriate field labels and all content within form tags need to be explicitly associated to a form control. Post-submission responses (errors or confirmations) must be perceivable. If you are using the default WordPress comment or search forms, these pass the accessibility-ready criteria.
“The changed requirement wouldn’t encompass all the accessibility-ready requirements to be present on the standard themes, nor would it automatically make them accessibility-ready, but by incorporating one by one requirements, through longer time period, the idea is to encourage theme authors to write accessible themes out of the box,” TRT member Denis Žoljom said.
The team is also re-examining the efficacy of the Trusted Authors program and whether there is evidence for discontinuing it. They are considering removing the child theme queue, which was incentivizing authors to submit more child themes since the queue moves faster than the regular one.
Imposing stricter accessibility requirements for WordPress.org themes is one suggestion that theme authors discussed over the weekend as a potential response to WordPress.org’s growing problem with crippleware. The expectation is that stricter requirements would shorten the queue of themes ready for review and perhaps even motivate companies to invest in accessibility testing to improve that process. While it may not have a direct affect on theme companies’ ability to produce crippleware, it makes the barrier for entry higher so that reviewers have more time to focus on improvements to the directory and the review process.
The new accessibility requirements will apply to all themes hosted on WordPress.org, not just new ones entering the directory. Existing themes will be expected to meet the requirements as they pass through the review process for updates. However, the team will not be actively hunting down old themes to suspend them. Today’s decision marks an important turning point that has the potential to have a ripple effect across the entire theme industry, as WordPress.org sets the standard for theme development. These new requirements give legs to WordPress’ commitment to accessibility in what TRT member Justin Tadlock called “a small but major step toward accessibility for all in the directory.”
In this episode, John James Jacoby and I are joined by Rachel Cherry, Senior Software Engineer for Disney Interactive and Director of WPCampus and Brian DeConinck, a front-end designer and developer with the OIT Design and Web Services team, part of the Office of Information Technology at NC State University.
We learn how Tenon was chosen as the vendor to perform the audit and what conditions needed to be met. We then dissected the results of the Gutenberg Accessibility Audit conducted by Tenon. We discuss the state of Gutenberg’s accessibility, recommendations for those in Higher Education environments, and where Gutenberg development might go from here.
Next Episode: Wednesday, May 15th 3:00 P.M. Eastern
Subscribe to WordPress Weekly via Itunes
Subscribe to WordPress Weekly via RSS
Subscribe to WordPress Weekly via Stitcher Radio
Subscribe to WordPress Weekly via Google Play
Listen To Episode #351:
Podcast: Play in new window | Download (Duration: 1:18:31 — 57.6MB) | Embed
Subscribe: Apple Podcasts | Android |
WPCampus has published the results of the Gutenberg accessibility audit the organization commissioned from Tenon, LLC. The audit was crowdfunded by the WordPress community and Matt Mullenweg and Automattic pledged to cover the balance to ensure it would be fully funded.
Tenon’s analysis includes a 329-page technical audit of the editor along with user-based testing that included people with various disabilities. WPCampus’ announcement presents Tenon’s findings in a measured and diplomatic way, encouraging the community to use the report for improving WordPress:
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.
Beyond its use for WordPress core, the audit is also a valuable resource for those extending Gutenberg and more broadly for developers who are building React-based projects.
Tenon’s report includes a 34-page Executive Summary, highlighting key findings from the usability testing and technical review. It’s important to note that the audit was conducted on WordPress version 5.0.3 in January 2019. Since that time the Gutenberg and Accessibility teams have resolved an additional 116 accessibility issues, which will be included in WordPress 5.2 next week.
As expected, Tenon’s results show that overall the markup generated by Gutenberg is “clean, semantically correct and accessible” but that “Gutenberg’s user experience is consistently poor.” The audit found that Gutenberg fails to comply with all 30 of the WCAG 2.1 Success Criteria.
Tenon’s findings confirm the statement WordPress’ Accessibility Team published in October 2018 regarding the editor’s overall level of accessibility:
“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.”
At that time, many WordPress contributors urged leadership not to ship an editor with critical accessibility issues that prevented people using assistive technologies from moving forward with the latest version.
Tenon’s Executive Summary concludes that the new editor is a step backwards for people with disabilities:
Gutenberg has significant and pervasive accessibility problems, the likes of which amount to a step backwards for users with disabilities over the legacy editor. Our user-based testing – backed by data from our technical review – indicates that the accessibility problems are severe in nature. We feel concerned that Gutenberg’s current accessibility issues will prove problematic for website owners who deploy Gutenberg to content creators in protected populations or for website owners who are themselves part of a protected population. Therefore, organizations which have high risk profiles should consult legal counsel before using it and may want to choose to use the legacy editor instead.
Tenon recommended that Gutenberg’s developers aggressively tackle the issues uncovered in the technical report, given the size of WordPress’ user base. The full report essentially functions as a guide for anyone who wants to contribute to the new editors’ accessibility. It is an excellent resource that outlines each issue with solutions and recommended code, making it easy for developers to get started with meaningful contributions right away. Tenon has created a collection of 84 issues on GitHub based on the findings in the audit and six of them have already been resolved/closed.