Accessibility issue with the search navigation keyboard shortcut

[markteekman]

What version of starlight are you using?

Latest

What version of astro are you using?

Latest

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Firefox

Describe the Bug

Considering to use this theme as the documentation website for my Accessible Astro projects and found an issue with the search keyboard shortcut, which is in violation with success criterium 2.1.4 (Character Key Shortcuts). It states the following:

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off A mechanism is available to turn the shortcut off; Remap A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt); Active only on focus The keyboard shortcut for a user interface component is only active when that component has focus.

One solution would be to implement a two character activation, like cmd+k for example 🙂

Link to Minimal Reproducible Example

https://stackblitz.com/github/withastro/starlight/tree/main/examples/basics?file=README.md

Participation

• [X] I am willing to submit a pull request for this issue.

[delucis]

Thanks for the report @markteekman! Accessibility is a high priority for us, so would definitely like to address this.

We actually already support cmd + K as well as the advertised / shortcut, so one solution could be to switch to using that exclusively? Curious what others think.

The main technical challenge will be that the modifier key shortcut varies depending on the user’s OS, so needs to dynamically display Ctrl + K and Cmd + K once the platform is detected. (It also takes up more space than the / character, so I guess there’s also the option of not advertising the shortcut at all, although I don’t love that.)

[markteekman]

Hey @delucis! Great to hear that accessibility is such a high priority 💪🏼 I did a quick glance at the theme and it's looking really solid. When I've got some more time I wanted to perform an accessibility audit to further help enhance the theme (changes are nothing big is going to pop up though!).

The solution would indeed be to switch to cmd + k / ctrl + k as the default option. Not advertising the shortcut wouldn't be a good idea because then people won't be able to reconize it's existence 🤔 I did see an example of the changing modifier depending on the OS on the React Router docs which uses algolia:

[HiDeoo]

Sharing a bit of informations as I had to deal with the same issue on a project in the past which also followed the “Accessibility requirements for ICT products and services” (EN 301 549). The latest version states the following when it comes to simultaneous user actions:

Where ICT has a mode of operation requiring simultaneous user actions for its operation, such ICT shall provide at least one mode of operation that does not require simultaneous user actions to operate the ICT.

A note specifies that this includes "having to press two or more keys at the same time".

Something to also note is the initial goal of the 2.1.4 criterion:

The aim of 2.1.4 is really more specifically about voice access / speech recognition, and accidentally triggering shortcuts when speaking inadvertently while the AT is listening, and then firing emulated keystrokes/key sequences to the page (where they do trigger JavaScript key events)

Considering the contradiction between the two, at the time we decided that in the specific case of search, we would accept that / was not something that could easily be triggered through voice compared for example to just k and we ended up supporting both cmd/ctrl + k and / (which I think is the current behavior of Starlight).

Not saying that this is the right way to go, but just sharing some informations that might help in the decision making process.

[markteekman]

Thanks for chipping in @HiDeoo! I asked a buddy of mine (Niek Dekrsen) for his input (he audits websites practically everyday 🙂) and he said that this criterion is based on chapter 9, 10 and 11 of the 2016/2012 European guidelines. In 9.2.1.4 specifically it mentions: "Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 2.1.4 Character Key Shortcuts". This means it limits the use of single characters, other then what's allowed in a software application in your example.

[HiDeoo]

Thanks you and your friend for all the extra informations and details, super helpful and appreciated. I've opened a PR removing the conflicting shortcut.