Introduction

This is the first in a series of tutorials on using WordPress’s block editor with a keyboard. We’re assuming that you’re using a screen reader as well, but we’ve also tried to include keyboard navigation tips for times when a screen reader is not present.

Inserrting a new block

When starting a new page or post, a dialog appears welcoming you to the block editor. Move to the “close this dialog button” and press either spacebar or enter to dismiss this welcome dialog.

From the blocks toolbar choose to add a new block, by either pressing the spacebar or enter key on the appropriate button. A place holder for a new block is inserted into the content area which prompts the user to start typing or press the slash (/) key to choose a block type.

Choosing the heading block

With focus on the block place holder, press the slash (/) key to choose a block. A list appears with 81 items in which to choose the option you need. The number of items in this list may change, however, at the time this was being documented only 81 items were available in WordPress 5.5.1.

Use your up and down arrow keys to navigate this list until you get to the heading item and then press the enter key. Do not attempt to use first letter navigation in this list as it does not work, only the arrow keys.

Changing your block layout

As you continue to compose your page or post, the blocks are enumerated 1 of 10, 2 of 10, and so on.

To move your block up or down in the hierarchy, first make sure you’re focused on the block and then press Alt + F10 to bring up the block editing menu.

Use your right and left arrow keys to navigate this menu. As you press the right arrow keys, the first two (2) options on this menu bar is the buttons to move either up or down one (1) block at a time. Choose the appropriate button, and press the spacebar or enter key to maneuver the block into the position of the hierarchy you desire.

Choosing your heading level

By default when a heading block is inserted into the content area it is automatically designated . as a heading level two (2) element.

To change the heading level, first make sure to be focused on the block and press Alt + F10 to bring up the menu bar, and right arrow to the button for heading level.

Press your spacebar on this button. A list of buttons appears for each heading level, to navigate this list, however, you will need to use the left and right arrow keys to choose the heading level you desire.

Once you have the heading level, press either your spacebar or enter key to confirm your choice.

Inserting text into the heading block

To insert text into the heading block, just simply start typing if you have your focus on this block. Screen reader users will need to make sure that their screen reader of choice is in either forms mode or editing mode.

Editing text in the heading block

Editing text in the heading block can be a little tricky at first with a keyboard, however, it can be done with practice.

Make sure you have the heading block focused, then use your arrow keys to navigate to the text you wish to edit. Use your keyboard commands for selecting text and make your modification.

WPTavern disagrees with Studio 24’s decision to drop WordPress over Gutenberg. I was going to write a long comment on that post, but then I figured I’d just address it on my site.

The Tavern’s disagreement hinges on the W3C prioritizing accessibility over its commitment to open source. And I’m wondering why that’s a bad thing.

Open source as a rule, (and FLOSS in particular, from Stallman on down), continues to consider accessibility one of those things that should be left up to the choice of the developer instead of something that should be implemented so that everyone can enjoy the freedoms granted by the GPL and other licenses. And anyone who has spent any time advocating for accessibility within the free spoftware space knows this. There’s a reason advocates are giving talks about the rights aspect of this instead of technical talks.

That talk’s from 2017, and I can’t think of another talk given by an accessibility advocate in that space since then. I can’t speak for anyone else but I get the impression we’ve finally just given up on trying to convince the Free Software movement that accessibility should be a requirement instead of a nice-to-have at best.

So it’s kind of nice to see the W3C flip tables over this.

Prioritizing accessibility over open source/free software isn’t the wrong thing to do, it’s the right thing to do, especially given the state of accessibility in the FLOSS space.

With regard to Gutenberg specifically, out of the eight projects I’m working on right now, two clients can use it without wanting to throw something, and only one of them really enjoys it. That client doesn’t have a disability and doesn’t use assistive technology. I still find Gutenberg to be an efficiency nightmare, and I’ve been using it for seven months now. And while I don’t think there’s a person alive who would say that the accessibility of the thing hasn’t improved, the part of that talk by Joe Dolsen left out is that the issues that have been closed and the accessibility successes are a start.

There’s also this, from his post on this subject:

When I read that statement, I feel like it implies that I gave a positive report on the accessibility state of Gutenberg in a way that isn’t really accurate.
Both those statements are absolutely true: two-thirds of the issues reported in the initial accessibility audit of Gutenberg have been solved, and the
overall accessibility is, indeed, vastly improved over the release, as would be expected given the first piece of information.
But it ignores the fact that those accessibility issues are not the only concerns raised on the project. They only encompass issues that existed in the
spring of 2019. Since then, many features have been added and changed, and those features both resolve issues and have created new ones. The accessibility
team is constantly playing catch up to try and provide enough support to improve Gutenberg. And even now, while it is more or less accessible, there are
critical features that are not yet implemented. There are entirely new interface patterns introduced on a regular basis that break prior accessibility
expectations.
And the statement that Gutenberg is vastly more accessible than at release is not particularly significant. At release, it was woefully inadequate; now
it’s bearable and largely usable, but in no way enjoyable. And in certain respects, it is lacking extremely basic features, such as support for adding
video captions within Gutenberg.

Note also Joe’s comments regarding WordPress and internationalization. They’re important, and I’m seconding them completely.

Improvement is excellent, but it’s not done. And speaking as someone who has to use Gutenberg on a pretty regular basis, it’s not ready to be deployed if you’re concerned about whether or not people with disabilities can add content to your system.

I hope that the W3C’s decision will convince WordPress’s leadership to prioritize accessibility at a higher level. But hope is not a strategy, and I don’t think organizations or individuals should be expected to stick with something that clearly isn’t meeting their needs or is even causing problems for the sake of their devotion to FLOSS.

I think Gutenberg is a great idea, despite the all-too-frequent flare-ups that still happen over accessibility issues. But I definitely don’t enjoy using it, and I don’t know any people with disabilities who enjoy using it either. And WCAG 2.0 is the minimum. You could completely conform to WCAG 2.0, and it doesn’t mean you’ve created something people with disabilities can use as effortlessly as everyone else.

Until Gutenberg gets to a point where it’s as easy to use as the classic editor, (if it ever does), organizations who either employ or want to employ people with disabilities are going to continue to drop WordPress over it. And telling them to fork WordPress or to maintain the classic editor plugin after WordPress stops doing that isn’t a solution to the problem. It’s about the most obtuse thing that could be said.