The AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team shares their expertise to improve the accessibility of WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and resources.
Ask general questions during the Team Office Hours every Wednesday at 14:00 UTC in the accessibility channel in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
How accessible is GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ in its current state (version 2.4)? To answer this the AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team set up a list of minimum requirement, did code reviews and research, gave recommendations and set up user tests.
The short answer is:
Gutenberg still needs extensive work to meet basic standards, like keyboard accessibility and semantics
Especially for screen reader users, Gutenberg as it stands right now is a dramatic step back in usability
We need to write a manual/documentation for assistive technologyAssistive technologyAssistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks.
https://en.wikipedia.org/wiki/Assistive_technology users
From the start
During development, almost from the start, Andrea Fercia (@afercia) did extensive a11yAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) (accessibility) testing and research. He and others created issues labeled accessibility on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ to address the issues found (Andrea created more than 50 of them).
At the moment 70 a11y issues are open, 166 are closed. A lot has been addressed, but there are still very important issues open (like for keyboard accessibility, tab order and navigation).
User testing
When Gutenberg 2.3 was released, Tammie Lister (@karmatosed) considered it ready enough for a complete accessibility test.
We wrote a user test, that includes the basic functionality needed to publish a post. Like add a title, headings, paragraphs, a list, a table an image and a video, use the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. options and publish.
On our testserver wpaccess.org we installed the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, version 2.3, and gave our a11y test team access. Joe Dolson also recruited accessibility experts for a test of version 2.4 at the CSUN conference. All results are reported in the Google spreadsheet Gutenberg a11y test results.
So far we’ve got good quality test results for
Keyboard only
Dragon Naturally Speaking
VoiceOver / Safari
NVDA / Firefox
Andrea created new GitHub issues from the reported problems or added extra information with the already reported ones.
Videos with user tests
Note: These users (Eric Wright and Sina Bahram) are leading accessibility experts, using their assistive technology on a daily basis and using WordPress for their work.
Minimum requirements before merge
To set a baseline, what should be fixed before merge we set up a list of requirements:
Keyboard navigation through blocks needs to be greatly simplified and streamlined
For some components, there’s the need to constrain tabbing within the component (i.e. they should behave like “modals”)
The publishing flow needs to be simplified, currently its accessibility is terrible
Everything needs to live inside the landmark regions
Text mode: a simple textarea is the only guarantee to enable users to publish content, regardless of the device / technology they use
Write documentation for keyboard and screen reader users.
Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick, see issue #3218
Block toolbars position counter intuitive for keyboard users, see issue #3976
The Date picker must be keyboard accessible
Severe issues
One of the most severe issue is the keyboard accessibility. The keyboard tab order is unpredictable. The tab order for and backwards is not the same. Publishing a post is a puzzle and the date picker is unreachable with a keyboard only.
Another issue is the need for quick navigation tools, like shortcuts and better use of landmarks and headings. There are so much more actions to take for adding or modifying a block. Compared to the current classic editor, publishing a post with a screen reader takes much more time and effort.
Because the extensive use of icons, voice recognition users have to guess the accessible names for buttons to activate them. This needs a design decision.
Actions to take
Fixing the keyboard accessibility and screen reader navigation is a high priority. Andrea opened issues for this and we need to prioritize these
At WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. London and Europe we will do extra user testing with assistive technology and discuss the results with Tammie Lister and the Gutenberg developers present
The accessibility team needs to take responsibility for the manuals and documentation. This documents only can be written after the minimum requirements as listed above are met