Change keyboard navigation keys

[pols12]

Hi!

I have enabled “Always use the cursor keys to navigate within pages” (Accessibility option) in my Firefox, in order to easily navigate in text content, copy, paste, see overflowing text…

However since #1095, I cannot use arrow keys in these purpose any more. That’s why it would be nice to change the attached shortcuts.

However, I know I’m a rare user to have this issue, I would understand a WONTFIX status.

[waylan]

While I'm certainly sympathetic to supporting accessibility options, we discussed the shortcuts pretty extensively in #1095 and ultimately decided to copy Sphinx shortcuts. Sphinx has a much larger user base than MkDocs, so if this is an issue, I'm curios why they haven't encountered it (maybe they have, I haven't searched there project).

I guess my question is: is the Firefox option a common paradigm or unique to Firefox only? If it is common across multiple platforms, then we shouldn't interfere with it. However, if it is simply some experimental one-off, then I'm not so sure we need to do anything.

[pols12]

There is no accessibility feature in Chromium core, but official accessibility plug-ins include Keyboard Navigation by Google Accesibility.

[waylan]

Interesting, but I also can find multiple plugins which use Vim shortcuts for the same features. The problem is that whichever set of keys we use, we are likely to break someones preferred shortcuts. That said, accessibility is more important than user preferences. So, for example, if we use vim shortcuts and that interferes with a user's vim plugin, we can say we had to use those shortcuts so we didn't break accessibility. But the real question is, which set of shortcuts should we use?

[waylan]

As an aside, the keyboard shortcuts are theme specific. You may find some third party themes that use different shortcuts (or none at all). Some themes might even make them configurable. That said, the default (builtin) themes should follow best practices.

[waylan]

Here is my proposal to resolve this issue:

1. Use n/p for next/previous by default.
2. Add theme specific settings (theme.shortcuts.next, ect) to allow users to override the defaults.

While n/p is very English-centric, it matches our use of s for search. And by making it customizable, a project in another language can change the defaults to whatever makes sense in their language. If a user really wants to use the arrow keys and disregard the accessibility conflict, they can. And by using theme specific settings, we are not adding any more settings to MkDocs itself.

The one concern I have it how to designate the key codes in the settings. The JavaScript code which acts on the keypresses requires the numeric key code which does not change for a given key regardless of keyboard layout. But users may not always know what the key codes are. We could point people to http://keycode.info/ to get the key codes for them to enter as values to the settings. or we could allow chars as values and try to convert to a keycode. Not sure how reliable or easy that conversion is for different keyboard layouts though (looks to not be straightforward -- read the comments as the "accepted" answer is apparently wrong).