<sl-menu> and <sl-menu-item> regression in 2.0.0-beta.79 caused by allowing focus on disabled items for improved accessibility

[CetinSert]

Describe the bug

Disabled (and also not displayed (CSS: display: none)) menu items allow focus (via keyboard o__O and mouse).
This weird behavior introduced in 2.0.0-beta.79 potentially for project-internal consistency runs contrary to all established expectations.

No other desktop/web app allows focus on disabled menu items (even when these are still displayed) via keyboard or pointer.

Please see examples below. I can add dozens more to convince you to revert this regression.

@claviska

[CetinSert]

Windows / Notepad

press ↓ key	result

Pointer focus is also not possible for disabled items.

[CetinSert]

macOS / Finder

press ↓ key	result

Pointer focus is also not possible for disabled items.

[CetinSert]

web / vscode.dev

press ↓ key	result

Pointer focus is also not possible for disabled items.

[CetinSert]

web components / Adobe Spectrum

press ↓ key	result

Pointer focus is also not possible for disabled items.

[CetinSert]

Vaadin: https://vaadin.com/docs/latest/components/menu-bar/#disabled-items (focus not possible via keyboard and pointer.)

[claviska]

This wasn't sitting right with me either. I've always heard and read — although I can't find the W3 site that says it at the moment — that disabled items should be focusable contrary to what operating systems and even form controls in the browser do.

This is inconsistent, as demonstrated here:

https://jsfiddle.net/8rh9o7ut/

I've also been in the room for multiple arguments about whether form controls should ever even be disabled, which seems to be more of a tabs vs. spaces-style discussion. I did some more reading on this and reverted my opinion with one condition that I've outlined in the contribution guidelines, (emphasis mine):

Focusing on Disabled Items

When an item within a keyboard navigable set is disabled (e.g. tabs, trees, menu items, etc.), the disabled item should not receive focus via keyboard, click, or tap. It should be skipped just like in operating system menus and in native HTML form controls. There is no exception to this. If a particular item requires focus for assistive devices to provide a good user experience, the item should not be disabled and, upon activation, it should inform the user why the respective action cannot be completed.

The bottom line is, sighted users expect disabled items to be skipped. This behavior saves keypresses and maintains consistency with operating system menus, form controls, etc. Additionally, disabled items are still discoverable by screen readers when using modifier keys (a common way to navigate HTML documents).

In this video, I arrow through the menu items twice. The first time, using Up|Down. The second time, using Control + Option + Left|Right.

This is the convention Shoelace will stick with unless there's definitive proof that this approach is wrong, harmful, or inaccessible to users.

keyboard.mp4