iFrame: Sometimes focus is lost with the Page List block in navigation mode

[alexstine]

Description

When in navigation mode, sometimes the focus is completely lost from the block select button. This needs a fix as it looks like this bug impacts all keyboard users and is not specific to screen readers alone.

Added a video this time so I could catch it in the act. Not sure if this is a regression or an outstanding issue. Needs a fix anyway.

Step-by-step reproduction instructions

1. Add a new post.
2. Enter a title.
3. Press enter and type some text to create a paragraph block.
4. Press enter and insert a navigation block.
5. Select an existing menu or create a new menu. Your menu should contain at least 1 child/inner block such as a search form, custom link, or page list.
6. Press escape to enter navigation mode.
7. Use your arrow keys to focus the navigation block.
8. Press right arrow to interact with inner blocks of the navigation block.
9. Notice how up and down arrows work fine to scroll through the list of inner blocks.
10. Press right arrow and observe the entire editor have a loss of focus.
11. Open the console.
12. Type the below command and press enter.
    document.activeElement;
13. Notice how the body tag is returned which signals a complete focus loss.

Screenshots, screen recording, code snippet

Video below.

video1433604524.mp4

Environment info

Gutenberg: trunk
Firefox and Google Chrome: latest
OS: Windows 10 Professional

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[alexstine]

@t-hamano I saw you tested my previous issue, can you give this one a look please? Interested to see if other Windows users can replicate.

Thanks.

[t-hamano]

Thanks for pinging me 👍

From what I have tested, this may be a problem with the page list block. This problem can be reproduced by the following procedure:

• Add a new post.
• Add a Page List block.
• Press the escape key.
• Press the right arrow key.
• Block editors will lose focus.

I have tested it on several blocks and so far it seems to occur only in the Page List block.

Posts.gutenberg.WordPress.-.Google.Chrome.2023-01-23.13-20-48.online-video-cutter.com.mp4

@alexstine
BTW: In my environment, with NVDA enabled, arrow key navigation on the block editor does not work. Do I need to customize the NDVA shortcuts?

[alexstine]

@t-hamano This is because Gutenberg does not properly handle screen reader modes for Windows. When you switch in to navigation mode, you probably heard a tone. Press your NVDA modifier key plus space bar to switch in to edit mode. Edit mode sounds like a typing sound. If NVDA is in browse mode, you are getting a virtual view of the DOM and Gutenberg keyboard events do not fire. If you switch to edit mode, Gutenberg manages everything for the screen reader. The problem that has been around from the beginning, NVDA does not know which mode to be in. Anyway, that is a much larger discussion for later. Hope this helps.

[t-hamano]

@alexstine
Thank you for the detailed explanation. If this issue can be treated as a separate issue, I would be happy to help 👍

[t-hamano]

I have looked into this issue further and believe it is a problem specific to the page list block.

The page list block has the following structure:

<ul tabindex="0" class="block-editor-block-list__block wp-block wp-block-page-list is-selected wp-block-page-list block-editor-block-list__layout" id="block-XXXXX" role="document" aria-label="Block: Page List" data-block="XXXXXX" data-type="core/page-list" data-title="Page List">
	<li class="wp-block-pages-list__item"><a class="wp-block-pages-list__item__link">Page 1</a></li>
	<li class="wp-block-pages-list__item"><a class="wp-block-pages-list__item__link">Page 2</a></li>
	<li class="wp-block-pages-list__item"><a class="wp-block-pages-list__item__link">Page 3</a></li>
</ul>

The li element is a core/page-list-item block, but unlike other blocks, it has only the class attribute.

In navigation mode, pressing the right key on a page list block is considered to navigate into a child block:

gutenberg/packages/block-editor/src/components/block-tools/block-selection-button.js

Lines 166 to 170 in 4f94f09

	} else if ( navigateIn ) {
	focusedBlockUid =
	getClientIdsOfDescendants( [ selectedBlockClientId ] )[ 0 ] ??
	selectedBlockClientId;
	}

Then it tries to select a child block at the following point, but fails to select the block, probably because the li element is not focusable:

gutenberg/packages/block-editor/src/components/block-tools/block-selection-button.js

Lines 197 to 199 in 4f94f09

	if ( focusedBlockUid ) {
	event.preventDefault();
	selectBlock( focusedBlockUid );

I can't come up with any specific code to solve this, but perhaps we should add a process to not focus the child block unless it is an operable block.

[alexstine]

@t-hamano Surely there is a way we can check if the element is focusable. I really cannot wait to do away with block selection button and just rely on the list view as it does not suffer from these problems. Maybe even hardcoding a check specific to the page list block would be okay but need to do something to fix the UX here. I think this has improved in other parts of the editor, I know in the list view, focus is only attempted if the element can receive focus. I do not think this should be refactored but quick fix would be great.

Thanks.

[alexstine]

@t-hamano

Thank you for the detailed explanation. If this issue can be treated as a separate issue, I would be happy to help

The editor is getting closer but I am still struggling with how to properly implement this. More issues will come once I finally figure out a good approach to handling Gutenberg native keyboard events and screen readers. It is worth noting that this is not a Mac problem as screen reader on Mac co-exists with the OS. Hard to pass any blame to Gutenberg devs who tested with Mac only expecting everything to be fine. Mac vs. Windows is a whole other discussion...

[annezazu]

Doing a sweep of high priority labels and am removing the label from this issue as, from what I'm reading, this is isolated to the Page List block and touches on a broader navigation mode experience, which touches on a larger convo around consolidating/prioritizing list view instead. I've renamed the issue to help make this issue a bit more actionable for now and want to note it for @getdave as the navigation block efforts continue.