Block inserter dialog has unexpected tab stop

[getdave]

As reported in #46939 (comment) the Block inserter dialog has random tab stop. This needs to be removed.

See also #24975

[ntsekouras]

Do you refer to the case when the container is scrollable? Because that it seems is how it needs to be implemented. See #46580 and https://chromestatus.com/feature/5231964663578624.

[getdave]

Do you refer to the case when the container is scrollable? Because that it seems is how it needs to be implemented. See #46580 and https://chromestatus.com/feature/5231964663578624.

Good question. I'm not sure. I'll take a snapshot of the point in the video from @alexstine post it here and see if it's related.

[scruffian]

This seems to be happening when the block inserter has scrollbars. The extra tab stop enables keyboard users to scroll the panel using the arrow keys.

(Note: The block inserter only has scrollbars on Windows which seems like another issue we should fix)

@alexstine does it therefore make sense to keep this tab stop? I appreciate that it doesn't add value for blind users, but for sighted keyboard users it is serving a purpose.

[alexstine]

@scruffian No, it never makes sense to keep an empty tab stop with no meaningful label for screen readers. It is extremely confusing. Anyone up for doing some research and figuring out how to label it so it works for sighted users and screen reader users?

CC @joedolson

Thanks.

[scruffian]

I'm happy to help solve this one, but I'm not sure what needs to done. I tried adding a label and a role to the place where the tab stop is here: #47121. Feedback/direction welcome.

[joedolson]

An empty tab stop creates frustration - because a user has no idea what they're missing, and can't differentiate between "this is an accessibility error" and "this is not something I need." So even if the purpose of the tab stop is only for sighted keyboard users, it should be labeled for screen readers.

Also, since keyboard users may be sighted, the tab stop should have a visual cue to provide affordance - as it is, it theoretically provides access for sighted keyboard users, but there's really no way for those users to know that.

If this control is kept, I suggest two things:

1. The tab stop should become visible on focus. It could display arrows pointing up and down, for example. This gives visual affordance to what the tab stop does.
2. The control should be labeled with function: 'use arrow keys to scroll blocks up and down'.

However, I'm not sure this control should be kept. What benefit does a keyboard user get from scrolling the list? If a user focuses the scrolling, then uses the down arrow to move to the bottom of the scrollable panel, then their next tab stop is still the first item in the list. So this feature is really only benefiting users who are mixed keyboard & pointer users - if they can scroll with the keyboard and then select with the mouse.

[jasmussen]

This tabstop seems like a bug, I don't think that inserter is meant to be scrollable, and in my interaction with it, it behaves expectedly as a modal:

• Focus set on the first tabbable
• Tab loops
• Tab to the list of blocks enables the roving arrowkey nav for selecting a blocok
• Esc closes and sets focus back on the opener:

GIF showing this:

Given there's a scrollbar visible in Windows, it seems like the bug to fix may be to simply make that scrollbar not appear (which is to say, find out what invokes it and fix that).

[joedolson]

@joen So, that's not the inserter I was testing; I was looking at this one:

Block/Pattern inserter with scrollbar.

[getdave]

Just noting the inserter @jasmussen is looking at is the one referenced in the Issue

See this screen shot

https://user-images.githubusercontent.com/444434/211516537-cd3d2838-0c1d-4ece-b5a4-3121e3e0ae6e.png

[joedolson]

I think that it doesn't make a significant difference; in both cases, there's an extraneous tab stop that doesn't provide value to the user.

[annezazu]

Does this still need accessibility feedback? How can we move it forward? I'd like to add a needs dev label and add to the Polish board :)

[joedolson]

I think the accessibility feedback has been given. I'm not aware of any additional feedback required.

[alexstine]

Adjusted labels and moved into project. This should be set for dev.

[annezazu]

Fantastic, thank you.