Navigation menu block: blue selection border is inconsistent with other blocks

[enriquesanchez]

This issue comes from the the accessibility test performed by the Accessibility team (#20369). One of the issues raised was that navigating with a keyboard between parent and child blocks was difficult and unpredictable.

Moving between the main block and nested blocks was very difficult and unpredictable. There was no visible focus that gave a clear sense of place while exploring the blocks. It was very difficult to understand what was going - what mode am I in? Am I in the navigation block, or in a menu item?

As seen in the example above, while using the up/down arrows, the UI moves between edit and browse mode without this change being invoked by the user.

[enriquesanchez]

A suggestion here would be to have a consistent transition between modes. If I'm in 'Select' mode, let's keep the user in that mode until they choose to enter 'Edit' mode. The way it is right now, the interface switches between the two modes as the user tabs from child to child.

[enriquesanchez]

After further inspection and thanks to @karmatosed help, I was able to see that the issue here is not an unpredictable change between Select and Edit modes. What is happening is that the selected style (blue border) shown on navigation items made me think the modes were changing.

What I expect is a consistent experience when moving from block to block, whether that's on the root level, or a child link inside the Navigation block. To me, this means that if I'm in Select mode, blocks should have a blue order, and if I'm on Edit mode, blocks should not have the blue selection border andI should be able move between lines of text the same way I do between paragraphs.

[talldan]

@enriquesanchez I think what's happening is that when a selected block has a caret within it, the blue border doesn't show. I imagine this is to make the typing experience clutter free.

When a selected block doesn't have a caret, the block border is shown (e.g. when an image block is selected).

The link block definitely can be selected without the caret being moved to the block when its padding or arrow is clicked, and that makes the border appear.

I'm not quite sure why using arrow keys makes the block lose its caret momentarily. The order blocks are navigated also seems like something that should be fixed. That might be worth a separate issue.

[mrfoxtalbot]

The Navigation Block has gone through a few iterations since this issue was discussed. Could you please confirm if you think this is still a problem, @talldan, @enriquesanchez? Thank you!

[talldan]

I'm not sure really, I think it still works in a similar way.

I don't think Enrique is contributing to the project any longer, so may not answer. This will probably need to be looked at by an accessibility rep and a designer.

[mrfoxtalbot]

Thank you for helping move this forward @talldan

[carolinan]

I would like clarification if the modes here refer to screen reader "browse" modes or the edit and select modes in the block editor?

I am testing on macOS, Chrome.
Keyboard testing without a screen reader:

While using the up/down arrows, the UI moves between edit and browse mode

Starting in the default edit mode, I am not able to reproduce this. I am able to reproduce the missing blue border when the caret shows, but I am not sure this is a problem.
But I want to mention that the page list block and regular links and submenus behave differently, and this is confusing.

1. I navigate to the block using arrow keys. The selection border is around the block.
2. When I press the down arrow key, I am unsure if I will navigate away from the navigation block or select the first menu item. It selects the first menu item.
3. When I am on that first menu item, pressing the up or down arrow keys does nothing. Pressing enter does nothing. Pressing the spacebar does nothing. If I did not know that this first item is a page list and if I did not know that the page list is not editable, this would be very confusing, and I would ask why I can't change the link text.
4. Pressing the left or right arrow keys selects the next menu item, and the item has a blue selection border. As soon as this item is selected, the submenu item is expanded, too.
5. I press the down arrow key, and as described in the issue, the blue border disappears, and the caret becomes visible instead. I don't find the missing blue border confusing, I am able to tell what I am editing.
6. Pressing the down arrow key again selects the submenu item, and it has a blue border: Press the down arrow key one more time, and the caret shows in front of the text in the submenu item.
7. But I don't want to edit this item, I want to add a second item to the submenu. I am expecting that when I press the down arrow key again, it should select the inserter button and clearly show me that the inserter button is selected: but it doesn't.
   Instead, pressing the down arrow key only moves the care to the end of the text.
8. So, I try to navigate back to the navigation block main row to add my item there, instead of in the submenu. But there is no way to navigate to the inserter with the keyboard. I take a chance and press enter, because maybe the inserter actually is in focus, but it has no visible focus style, but pressing enter adds a new paragraph below the navigation block.

Screen.Recording.2023-08-16.at.11.40.47.mov

[carolinan]

Select mode: This is bad, but a separate issue should be created for it.

My example menu, by chance, has a page list as the first menu in the navigation block. And I can't navigate past that block using the keyboard.

1. I enable select mode.
2. I navigate to the navigation block using the arrow keys.
3. When the navigation block is selected, pressing the down arrow key correctly navigates to the next block. This is what I would expect.
4. Going back to the navigation block, I press the right arrow key, and the first menu item is selected. It has a blue border.
   I press the right arrow key, and now a modal opens saying that if I want to edit the page list, I have to detach it.
   I select the cancel button in the modal. To reach it, I needed to use the tab key, but that was not a problem.
5. I have pressed cancel, and the focus is returned to the page list item that I was originally: This is the expected behavior.
6. Now, the problem is that I try to press the right arrow key again to move to the next item, but the editor just keeps opening the modal, so I can't get past the page list.

Screen.Recording.2023-08-16.at.11.46.43.mov