Disable more keyboard shortcuts if off in Settings

[alex-key]

Describe the bug

There are multiple places, where keyboard navigation still has custom implementation and disregards state in user settings:

• Search (ArrowUp, ArrowDown, Enter)
• Compage page (ArrowUp, ArrowDown, Enter)

The following removed from the scope after clarification (arrow navigation is ok in this widgets):

• Package page > Playgrounds selector (ArrowUp, ArrowDown, Enter, Escape) example
• Package page > Package manager selector (ArrowUp, ArrowDown, Enter, Escape)
• Package page > Readme headers selector (ArrowUp, ArrowDown, Enter, Escape)
• Package Code page > Version selector (ArrowUp, ArrowDown, ArrowLeft, ArrowRight, Enter, Escape)

Need to disable ones that could be used with default keyboard navigation and decide about the rest which does not work w/o custom nav shortcuts

Additional context

[alex-key]

@knowler Hi Nathan. I've found that some shorcuts still use custom implementation (listed in the issue above). I create a PR to disable it for first 3 listed (they will use user settings value). As for the rest: I checked and if custom navigation is disabled - default navigation by pressing "Tab" does not work. Could you please advice - how this should be addressed?

Default example - package manager selector on any package page: https://npmx.dev/package/vue#get-started

• focus on button in GET STARTED section
• press Space - dropdown list is opened
• press Tab
• focused button is "copy" instead of the first item from the list of package managers

[knowler]

@alex-key Anything that is implementing shortcuts according to the WAI-ARIA spec does not need to be disabled by the setting. This means any of the list boxes (e.g. package manager selector, README table of contents) and the combobox on the compare page can stay as those are the default shortcuts for them and they are what make those widgets operable by a keyboard. The WCAG requirement (2.1.4 Character Key Shortcuts Level A) is mainly that single character keys can be disabled or that they are limited to a single widget.

So, for the setting, I would only include the keyboard shortcuts currently listed in the “keyboard shortcuts” modal and nothing more.

[alex-key]

Would it be intuitive for user without any hints, that arrows should be used in such dropdowns instead of Tab?
Also is closing dropdown or modal pressing Escape allowed per WCAG?

[knowler]

@alex-key Yes, that is the expected affordance of those controls (compare with native select, input with suggestions, radio controls). It would make it break for assistive tech if we disabled these essential keyboard controls.

[alex-key]

@knowler Just to clarify: navigation in search results (which is not dropdowns) using arrows still should be disabled in Settings. Correct?

[knowler]

@alex-key Yep, those can be disabled since they’re actually shortcuts and not essential for navigating/operating.

[alex-key]

I will update PR accordingly