The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
There have been some important questions and concerns about 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) in the upcoming new editor. First and foremost, it goes without saying that work on these areas is never finished and we can always go a step further in improving the experience for all users of WordPress. That is a big part of the project’s coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. mission. We need to continue to develop close feedback loops with different users interacting through their preferred tools to make sure what we build is relevant to their experiences.
A large amount of work and effort has gone in building mechanisms necessary to make the editor accessible for a wide user base, some of which will be highlighted in this post. For example, it is entirely possible right now to recreate the “demo post” that comes with the 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/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-partyusing the keyboard. In many ways, these tools are better and more sophisticated than what we offer in the current editor.
There are bugs, of course, and rough edges to still address. From release to release these have been refined and iterated by many people and I want to thank all of them for their hard work. There are about 270 tickets closed specifically labeled “accessibility,” and around 90 more that remain open, so we still need your help. The goal is to make this experience as seamless as possible for all users, so if you are encountering an issue, please share it so it can be addressed.
Let’s go over some of the accessibility related capabilities that exist right now in the new editor…
Gutenberg introduces a mechanism for navigating across the major regions of the application with a simple keyboard shortcut that cycles through them — headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., content, sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., publish flow are included. A user can press “Control + `” or “Alt + Shift + n” (this can vary based on keyboard configuration) to focus the different areas at any time. This is an entirely new addition to WordPress with the hope of streamlining navigation without a pointer device.
There is a wide array of keyboard shortcuts available to help access different functionality. These are built in a way that can be extended and integrated in testing flows. A panel listing most of the shortcuts can be accessed from the menu at the top of the editor or by pressing “Ctrl + Alt + h”. Tooltips used throughout the application also display their corresponding shortcuts when available. They range from editor functionality (save, undo, etc), to formatting options (adding links, italics, etc), to inserting new blocks (just type “/” on a new line), to navigation and selection of blocks. Keyboard shortcuts are contextual to the OS and displayed as such in tooltips and menus.
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. Navigation
The main mechanism for traversing blocks is using the arrow keys. There is also a Block Navigation panel that allows keyboard users to quickly navigate through blocks without having to tab through their controls or flow through their contents.
Slash Command and Insertion
It’s important to be able to add new blocks and manipulate them with ease without leaving the keyboard. There is a very convenient shortcut (“/”) to add new blocks. There are also shortcuts for adding a new block before or after the current block. If there are ideas on how to surface these better and contextually to users, please chime in!
Toolbar and Sidebar
Main block tools are grouped in the toolbar, while secondary actions are often deferred to the sidebar panel and both can be accessed through keyboard navigation. The sidebar can be toggled with a single keyboard command (“Shift + Command + ,“). The toolbar — whether it’s docked at the top of the block or at the top of the editor — can be accessed with “Alt + F10”. Using the arrow keys, all focusable areas of a block can be navigated to (including things like the optional caption field for an image or an embed, or the source of a quote).
We’ve worked hard to fix edge cases for users of high-contrast mode in Windows, to ensure users with vision issues that require high-contrast mode do not encounter bugs when using Gutenberg.
These components not only reduce the overhead of having to replicate UIUIUser interface controls and solutions, but also ensure consistency. Consistency is important so that learned behaviours can be transferred and interactions work as expected. Many of these components have built-in accessibility mechanisms, from things like containing focus within dropdown menus or modals, arrow navigation of menu items, to supporting and automatically assigning aria properties when possible. In combination with guidelines and tests, it can help ensure the editor and its extensions remain accessible to users beyond what core offers.
Helping the User Create Accessible Content
The editor also introduces helpful messages to the end user when using color combinations that might have contrast issues (it also takes font sizes into account for readability measurement) or when adding heading elements in the wrong order (like an h4 following an h2, for example). This is also a new addition that has the potential of both helping users learn and produce accessible content for their viewers, expanding WordPress’s commitment to web standards. These tools are also available for reuse by third-party developers in their own blocks.
Furthermore, the controlled nature of blocks means that the final HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. generated can remain semantic and accessible for viewers.
To speed up the process of content creation, there are quick formatting shortcuts that can be used when starting new lines. For example, using an asterisk followed by a space would automatically create a list block while using “##” would create a heading block.
Aria properties are also used throughout the application to inform about the purposes and meaning of controls and actions. This is an ongoing process that has benefited tremendously from the help of people like @afercia with a lot of experience in testing with different screenreaders and their intricacies (JAWS and NVDA, MacOS VoiceOver). It’s also a good place to lend a hand if you are familiar with them.
Automated End-to-End Tests
We have the ability to run and automate a full editor session in a browser. Using this, we can test a sequence of operations with the keyboard and validate the results. This will allow the editor to continue to improve while making sure things remain accessible and don’t regress interaction-wise. As an example: we test Block Navigation entirely with the keyboard and no mouse controls to ensure it is fully usable by keyboard users. This hasn’t been a well communicated capability, but it’s a great area for contributors to get involved with.
Speaking of such tests, this is a fully automated test that replicates the “demo” post using keyboard commands:
Current Issues and Improvements
The above is a partial picture of what is currently in place. There is still work to do, and I’m confident we’ll be able to get there together. The following are some of the pending bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and ongoing improvements on multiple fronts, many of which are landing in the next releases:
Improved block navigation for keyboard users and block hierarchy overview for screen readers. By modifying a feature only intended for nested blocks, the navigation between blocks can be vastly improved for keyboard users. This allows keyboard users to always have an “escape hatch” keyboard shortcut to navigate through blocks.
There’s also work to be done in better exposing many of these tools to end-users, specially around non-obvious keyboard navigation commands.
Huge thanks to everyone that has tested and contributed issues related to accessibility. It helps tremendously.
All in all, there is a significant volume of accessibility-specific tools and functionalities included in the plugin that already surpass comparable capabilities in the Classic Editor. This was the result of the work of multiple people’s collaboration that I hope continues to evolve and improve. It hasn’t always been easy among the product challenges and the new technologies involved and we need to collaborate better — communication is something that we need to always nurture and foster.
— Thanks to @lonelyvegan for collaborating on this post and the ongoing work.