It’s WordPress Accessibility Day
Today is WordPress Accessibility Day, a 24-hour global event dedicated to addressing website accessibility in WordPress. You can find out more about the schedule and sessions on wpaccessibilityday.org.
Progress report of the team’s goals for 5.6
We reviewed progress on the main team goals for WordPress 5.6:
- Updating the WordPress Accessibility coding standards from WCAG 2.0 to WCAG 2.1 and document accessibility anti-patterns
- Accessibility of the WordPress Twenty Twenty-One default theme
Updating the WordPress Accessibility coding standards from WCAG 2.0 to 2.1
The team started work on the documentation but we are still pending on gathering examples of anti-patterns found across WordPress’ interface.
Please reach out if you want to help with this task.
Accessibility of the WordPress Twenty Twenty-One default theme
Folks behind the design and development of the new WordPress Twenty Twenty-One default theme have already been at work creating and addressing accessibility-related issues.
Some of these issue have proven to be complex and feedback is welcome. The team feels that we need to clarify our goal of having the theme be AA or AAA ready.
Accessibility Statement feature plugin
Organize accessibility testing of the new Widgets screen
A call for testing the new Widgets Screen in Gutenberg 9.1 was posted earlier this week.
The accessibility team is planning and organizing a round of accessibility-related testing. The call for testing goes into detail on how to test and provides more details, but in summary, in order to test this screen you’ll need to:
- Have a site using WordPress 5.5.
- Make sure you use a theme that supports widget areas (e.g. TwentyTwenty).
- Go to the website’s admin.
- Install and activate the Gutenberg plugin. If you already have it installed, make sure you are using at least Gutenberg 9.1.
- Go to Appearance > Widgets.
- Notice that it visually resembles the Block Editor now.
We welcome any help with testing the new Widgets Screen. Whether you can test for keyboard access, screen-reader support, or any other type of assistive technology, a few tasks you can test for are:
- Navigate and have access to the whole interface
- Add/remove blocks and 3rd party widgets
- Move widgets around
If you’re specifically testing for keyboard access, please check that:
- any action can be performed easily with keyboard only
- the tab order is logical and meaningful
- there are no keyboard traps
- users are not forced to perform counterintuitive keyboard navigation to perform an action
Please open issues on the GitHub repository so these findings get addressed as soon as possible. In order to avoid duplication, we ask you to share in the #accessibility channel when an issue is created so everyone has awareness and follow along.
If you have access to add labels in the repository, the label we should be using for these issues is
[Feature] Widgets Screen.