Accessibility regression: Focus does not land in the paragraph for a new block when pressing Enter

[MarcoZehe]

Describe the bug
When starting a post and after entering the title, or after writing a paragraph, pressing Enter no longer puts focus in the paragraph of the newly added block. Instead, focus goes to the "Block" button above it. Windows screen readers such as NVDA then switch out of focus mode into virtual, browse, or reading mode, breaking the typing flow. The user has to down arrow and press Enter to put focus back into the paragraph to continue typing. This is very disruptive when thoughts are flowing and one expects to just be able to continue typing when pressing Enter for a new paragraph.

To reproduce
Steps to reproduce the behavior:

1. Go to your blog and start a new post. This also reproduces on wordpress.com, doesn't need to be self-hosted.
2. Type your title.
3. Press Enter.
4. Focus lands on the button that is either labeled Block or Paragraph above the actual paragraph.

Expected behavior
Focus lands in the paragraph of the newly added block so I can continue typing, or type a / to choose a new block type.

Screenshots
I am blind, so screenshots wouldn't do much good.

Desktop (please complete the following information):

• OS: Windows 10.
• Browser Firefox
• Version 70, 71 beta, or 72 nightly.
• Screen reader: NVDA 2019.2.1.

Additional context
From a chat in the WordPress accessibility channel on Slack, @aduth suspects this to be a regression from #16500. Similar to #17776.

[aduth]

A solution should include an end-to-end test which verifies that a user can proceed to type within a new paragraph after pressing Enter from the title field.

In this test suite, perhaps: https://github.com/WordPress/gutenberg/blob/master/packages/e2e-tests/specs/editor/various/writing-flow.test.js

[afercia]

This is certainly because of the new "Navigation" and "Edit" mode introduced in Gutenberg.

Note: these modes have nothing to do with screen readers modes. They're modes specific to the editor, where the interaction with blocks changes.

"Navigation" mode is active by default so after entering a post title in a new post the first Enter press brings users to the new paragraph block in "Navigation" mode.

Pressing Enter again switches to "Edit" mode and moves focus to the editable area.

Once in "Edit" mode, all the block user interface is revealed and available to users.

Creating a new block keeps the editor in "Edit" mode so pressing Enter creates a new paragraph in "Edit" mode and users can continue typing.

Only when pressing Escape the Editor switches back to "Navigation" mode. Note: screen reader users may need to press Escape twice: first time to exit the screen reader "focus mode", second time to switch the Editor to "Navigation" mode.

The main goal of this change is to provide a mechanism to make the blocks user interface not available when tabbing through the editor. Imagine a post with 20 or more blocks. In Navigation mode, users now need just 20 tab presses to go through all the blocks. At any time they can identify (more or less...) the block they want to edit and press Enter to switch to "Edit" mode.

Instead, without this new mechanism, users would be forced to dozens of Tab key pressed to go through all the 20 blocks.

Worth also noting this mechanism works only when tabbing. When using the arrow keys, it is still possible to get to the editable area regardless of the Editor mode. At least, it should work this way.

The main problems I see with this new feature are:

• On the related pull request it was asked to wait for extensive testing from the accessibility team before merging this feature. The extensive testing didn't happen but the pull request was merged anyways.
• Discoverability: there's nothing to inform users about this new mechanism.
• Lack of audible messages to announce the mode switching, as originally recommended on the first conversations about mode switching, see: Keyboard interaction: standardize the blocks behavior #2031 (comment)
• Documentation: whether or not it's documented in a Readme file, there's the need for something more helpful to users. The modes mechanism isn't an expected interaction: users are used to native behaviors and when there are good reasons to deviate from native behaviors, clear instructions needs to be provided. Gutenberg is progressively evolving in a custom application rather than a form-based one. This isn't good or bad per se. There are big web applications that are largely used by assistive technology users out there: they probably do a better job in providing instructions and help to users.

[MarcoZehe]

Thank you @afercia for this detailed explanation! This hit me by surprise on a production system, without any warning or indication of these modes. So I was indeed considering this to be a bug. Moreover, once NVDA is in browse mode, Enter actually performs a click on the button, not a press of the Enter key which could register with the application. So, even if I press Enter on that button and then that mouse click makes me go into the paragraph, I cannot be certain whether this also triggers edit mode. And as you said above, lack of any audible messages about the modes means I have no indication whatsoever that these two modes even exist. Granted, if I understood correctly, sighted users also don't get this indication. You have to be involved in the community here to actually know about these things. Wonder how many other keyboard users, not necessarily screen reader users, will be bitten by this.

If this is intended behavior, feel free to close and keep it as a reference to indicate that better indication of modes is urgently needed.

[aduth]

Worth also noting this mechanism works only when tabbing. When using the arrow keys, it is still possible to get to the editable area regardless of the Editor mode. At least, it should work this way.

Should that be interpreted to mean that this is a valid bug, i.e. it should be expected that pressing Enter or ArrowDown from the title field should allow the user to continue editing?

[aduth]

The main problems I see with this new feature are:

Do you know if there are existing issues to track these tasks?

[MarcoZehe]

I am OK with closing this bug in favor of something that adds a clear indication for screen reader users whether the editor is in navigation or editing mode. I've asked in #17088 whether that would be in scope there, since it deals with a lot of indication of modes.

However having said that, if just starting a post, with (at the time of writing the title) no block being present and the press of Enter adding the very first one, it can still be suggested that the editor be smart and save me one key press by putting me into editing mode then by default. After all, with only one block, there's not much to navigate to yet.

So, should this be closed, then? Or morphed?

[afercia]

Thanks for the improvements implemented in #18624!

Just a quick thing: the message

speak( __( 'You are currently in navigation mode. Navigate blocks using arrow keys. To exit navigation mode and edit the selected block, press Enter.' ) );

Should be changed to instruct to use the Tab key instead of arrow keys. While both work when using a keyboard, screen readers reserve arrow keys for their own navigation mechanisms. In other words, when using a screen reader the arrow keys still allow to navigate to various elements of the block UI. Instead, we want to give users a way to skip all that UI. When a screen reader is running, only the Tab key works well.