Potentially swap arrow keys and tab in rustdoc keyboard shortcuts

[Manishearth]

Currently rustdoc's keyboard shortcuts use Tab to cycle between the tabs at the top of search results, and the arrow keys for moving through search results.

It's much more common for Tab and Shift + Tab to be used for navigating a list, and you can autosupport this by adding tabindexes, I think those autoskip display:none elements as well. It's pretty bad form to override Tab. Perhaps we should use tabIndex for this and use something else for switching the search result tabs?

[GuillaumeGomez]

I never navigated a list using tab. I didn't even know it was a thing. O.o

Also, up and down arrows seem more accurate to me and this has been integrated. As a little "bonus", docs.rs uses arrows as well to go through crates.

However, we can talk about adding tabindex if you want?

[Manishearth]

tabindex won't work if we override tab, that's the problem

this is a well-established pattern

[GuillaumeGomez]

Even with tabindex, we'll still have to bind 'enter' key I assume to change the current search tab, no? Also, we can't bind right and left arrows to do this so we're kinda limited to find replacements. The last option would be to add a setting to disable like you proposed in #65211 I guess? But we have other issues to answer on this other one.

[Manishearth]

No, if you're using tab navigation the enter key should automatically work to "click" the currently selected thing. The browser functionality around this is quite robust, let's not reinvent it.

…

On Thu, Oct 10, 2019, 7:02 AM Guillaume Gomez ***@***.***> wrote: Even with tabindex, we'll still have to bind 'enter' key I assume to change the current search tab, no? Also, we can't bind right and left arrows to do this so we're kinda limited to find replacements. The last option would be to add a setting to disable like you proposed in #65211 <#65211> I guess? But we have other issues to answer on this other one. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#65212?email_source=notifications&email_token=AAMK6SC2KC2VI45ASMRD5RLQN4YZDA5CNFSM4I6TJNAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA4ORGY#issuecomment-540600475>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMK6SF2EQYCJ2LL4JCUBYLQN4YZDANCNFSM4I6TJNAA> .

[GuillaumeGomez]

TIL. One less thing to worry about. :)

[steveklabnik]

Triage: not aware of any work here

[GuillaumeGomez]

After coming back to this issue after such a long time, I think we should keep the current behavior.

[Manishearth]

I still disagree. I haven't had the time to prototype this, but this is very much not following the norms for keyboard navigation which has accessibility implications.

[GuillaumeGomez]

I don't see how accessibility can be impacted by this. I assume they don't go through text content the same way and that changing how the interactions are done will change anything for them. In addition to that, when included in docs.rs, adding more tabindex could be problematic depending on docs.rs evolutions (we added some tabindex there as well).

[Manishearth]

Firstly, keyboard accessibility is not only for the blind. People may prefer keyboards over mice for many accessibiltiy reasons. However, tab navigation is a huge part of accessibility for the blind in many cases.

In addition to that, when included in docs.rs, adding more tabindex could be problematic depending on docs.rs evolutions (we added some tabindex there as well).

No, that's the point, we don't actually need to add tabindex, currently we're overriding tab defaults via JS which is almost always really bad. The tab defaults for the page are quite good already, what would happen is that you would tab through focus on the top tabs, and then through all of the links and summary short strings. We may potentially want to exclude the summary short strings from tab navigation, but other than that we wouldn't be doing special tabindex stuff.

[Manishearth]

The largest problem here is that the moment you tab into the "tabs", your keyboard navigation is stuck there forever. Overriding browser tabbing with JS isn't always a problem but this is like one of the biggest reasons it usually is.

[jyn514]

Perhaps we should use tabIndex for this and use something else for switching the search result tabs?

Maybe we could use left/right arrows instead of tab for switching between 'In Names' and 'In Parameters'? I think that's more clear than tabs anyway.