Controversial use of the `role="menu"`

Hello! I found the KeyUX interesting. But I don't quite agree with using the `role="menu"` for widgets with arrow navigation. According to the [ARIA specification](https://www.w3.org/TR/wai-aria-1.2/#menu), `role="menu"` represents vertical (by default) or horizontal (when using `aria-orientation="horizontal"` or `role="menubar"`) sets of actions that users can invoke. This is similar to the command menu bar in most desktop applications. But it's not a set of navigation links or tabs as described in README.

This stems from a misunderstanding of the term "menu" in natural usage (as panel with links) and the term "menu" from the ARIA specification (as set of invokers). Also more about menu pattern describes in [ARIA AGP](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). It also gives an [example of a navigation menu](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/) with a `role="menu"`, but warns that this role is not entirely suitable in this case, although it can be applied.

For navigation aids `role="navigation"` + `role="link"` (`` and `` elements in HTML) should be used. For tabs `role="tablist"` + `role="tab"` + `role="tabpanel"` (there is no alternative in HTML) should be used. There are also many patterns that use arrow navigation between grouped elements instead of tab-key: listbox, toolbar, menubar, radiogroup, grid, etc. I think that using a single abstraction like `role="menu"` as an arrow navigation indicator, as in KeyUX, is not the best way.

Instead, I propose to look at [focusgroup proposal](https://open-ui.org/components/focusgroup.explainer/) from the OpenUI group and the [focusgroup polyfill](https://github.com/MicrosoftEdge/MSEdgeExplainers/tree/main/Focusgroup) for this proposal by Microsoft Edge team and make a similar or the same (for future compatibility with the focusgroup standard). This approach will allow developers to use suitable ARIA roles for different patterns and combine them with KeyUX arrow navigation.