See for example #1879

The DropdownMenu component is pretty good for accessibility and works pretty well, could also be further improved.

• it already uses role="menu" and role="menuitem"
• already implements arrows navigation
• it gets its items via props

Currently, it's used just for the Table Block:

Wondering if it could be used also in other places, for example:

• the block switcher (it's a menu and works in a similar way)
• the format list (same, even if it has some peculiarities)

Further improvements to consider:

• navigation should be implemented with arrows only (no Tab key!) and it's described in detail on https://www.w3.org/TR/wai-aria-practices/#menu

While the recommended pattern described above is a bit hard to follow, I'd strongly recommend to dedicate a few minutes to it to get how interaction should work.

The advantage of having just arrows navigation is that the amount of Tab key presses required for navigation is drastically reduced: users would have the choice to navigate through the main UI components with the Tab key and enter the menu with arrows key.

To get an idea, the ARIA Authoring Practices have also an example, I'd recommend to try the interaction on this menubar example:
https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-2/menubar-2.html

Worth noting the DropdownMenu currently uses a keydown event also for the Tab key, to move focus to the previous/next items. Not sure that's really needed, since the items are buttons so they're natively focusable and already in a correct Tab order. Regardless, the ARIA menu pattern requires just arrows navigation. The Tab key should be used to exit the menu.

TL;DR
More details on the expected keyboard interaction:

https://www.w3.org/TR/wai-aria-practices/#menu

When a menu opens, or when a menubar receives focus, keyboard focus is placed on the first item. All items are focusable as described in 4.6 Keyboard Navigation Inside Components.

4.6 Keyboard Navigation Inside Components
https://www.w3.org/TR/wai-aria-practices/#kbd_general_within

As described in section 4.1 Fundamental Keyboard Navigation Conventions, the tab sequence should include only one focusable element of a composite UI component. Once a composite contains focus, keys other than Tab and Shift + Tab enable the user to move focus among its focusable elements. Authors are free to choose which keys move focus inside of a composite, but they are strongly advised to use the same key bindings as similar components in common GUI operating systems