Improve DropdownMenu usage and consistency

[mkaz]

Describe the bug

The DropdownMenu component does not use the isSelected component, or highlight the proper item that currently selected. Additionally the hover and mouse states is not consistent.

To reproduce

Using the DropdownMenu component with a MenuGroup, like so

<DropdownMenu label={ __( 'Size' ) }>
	{ ( onClose ) => (
		<MenuGroup>
			{ sizeOptions.map( ( entry ) => {
				return (
					<MenuItem
						icon={ size === entry.value && check }
						isSelected={
							size === entry.value
						}
						key={ entry.value }
						onClick={ () => {
							setAttributes( {
								size: entry.value,
							} );
						} }
						onClose={ onClose }
						role="menuitemradio"
					>
						{ entry.name }
					</MenuItem>
				);
			} ) }
		</MenuGroup>
	) }
</DropdownMenu>

1. Just setting the isSelected attribute is not enough, an additional check is required to create and set the checkmark icon.

2. When the DropdownMenu is opened, the first item is highlighted (blue box) regardless of an item being selected. The selected item should be the one with the focus(?) blue box highlight.

3. When hovering over the menu items with the mouse, the text is highlighted but the blue box does not change. Compare to the OS menu when using a mouse to highlight, the items are highlighted with the mouse.

4. When using the keyboard to change items selected, the blue highlight box moves but the text does not show as highlighted. The highlight state should be consistent between 3 & 4 regardless of mouse or keyboard used to highlight

5. With the DropdownMenu highlighted, the down arrow key should open the drop down menu.

6. The DropdownMenu does not support a non-icon button, ideally we could create a text button to trigger.

[shaunandrews]

When the DropdownMenu is opened, the first item is highlighted (blue box) regardless of an item being selected. The selected item should be the one with the focus(?) blue box highlight.

When hovering over the menu items with the mouse, the text is highlighted but the blue box does not change.

The "blue box" is actually the keyboard :focus. I've seen many, many people confuse the focus indicator with a selection indicator.

[jasmussen]

As far as I can tell from the ticket and GIF, this is working as intended:

• A menu item hover state is blue
• A menu item selected state is a checkmark and/or a "toggled icon" (see alignments)
• A menu item focus state has a blue border

Chrome merges the hover and focus states, which you can do, but I'm almost convinced we've intentionally not done that, so as to not confuse what actually has focus.

The thing I believe trips up most people is that when you open a menu, the first item has a big blue focus rectangle, making it seem as though it's selected, even though it's just focused. Imagine you're using a remote control to navigate your TV box — when you open a menu, you need to know where your focus is, to know which arrow direction to press to get to the item you want.

The only actionable items I can see here are:

• Better indication for "Toggled". One thing we could do is show a checkmark next to the selected alignment, and not rely just on the inverted icon.
• Revisit focus rectangles. This one is tricky because they were just recently unified to always be blue borders, so at least you only have to learn a single focus rectangle style. But we could make that focus rectangle 1px wide in menus, instead of 1.5 as it is now?

Note that if we were to use the gray-background focus indication that Chrome and Google Docs uses, as best I can tell we'd need for it to use this gray, to meet AA contrast guidelines:

To clarify the above, since it's using white text on gray — I believe that the background color needs to have 3:1 contrast to adjacent menu items, which have a white background.

🙈

[mkaz]

Ok, that leaves me with two questions:

First, when the menu is open should we set the focus to the item selected instead of just the first item in the list? I think this would solve the majority of the confusion, but not sure if it would be appropriate/expected behavior for the control.

Second, with regards to (1.) above, should we default a selected MenuItem icon to check, I don't feel that strongly that we should, but it was surprising using the component the first time and not getting that behavior by default.

[jasmussen]

First, when the menu is open should we set the focus to the item selected instead of just the first item in the list? I think this would solve the majority of the confusion, but not sure if it would be appropriate/expected behavior for the control.

As far as my understanding of the accessibility of dropdowns, focus on the first item is also expected. So we can't do this. The solution likely needs to be visual in nature.

Second, with regards to (1.) above, should we default a selected MenuItem icon to check, I don't feel that strongly that we should, but it was surprising using the component the first time and not getting that behavior by default.

I think this is the most actionable next step, and probably worth trying.

[simison]

This issue might have unwanted consequences when tooltips are present for first menu item: #37470

[jasmussen]

Actually, coming back to this one, I think we should close it in favor of #43082. The thing is: the size can be in an unset state, and so it doesn't make sense to add a checkmark unless a size is explicitly set. 43082 discusses more holistic solutions to this unset state.

Secondly, focus being on the the first item inside a menu is expected behavior. That doesn't mean it needs to invoke the tooltip as is the main problem with 37470, so that seems separately solvable.