Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search box keyboard navigability #535

Open
towerofnix opened this issue Jun 26, 2024 · 0 comments
Open

Search box keyboard navigability #535

towerofnix opened this issue Jun 26, 2024 · 0 comments

Comments

@towerofnix
Copy link
Member

Just planning expected or prototype behavior here.

While search input focused:

Tab/shift-tab behavior is unmodified.

  • Press down to focus the first result. (Pressing down while there are no results does nothing, though it still prevents-default because the default text-cursor-navigation bound to up/down should never be available based on an automatic condition.)
    • Also save the text cursor position into memory.
  • Press up to do nothing. (This also prevents-default even though there is never an up-arrow action, because up/down are corresponding actions. Both should be disabled when one is disabled.)
  • Press escape to clear the search input. (This also clears any shown results. It does not de-focus the search input, it just resets to the initial/blank state so a new search can be entered, or search can be navigated away from any of the usual ways.)

Mouse behavior while search input is keyboard-focused:

No special behavior. Mousing while the search input is focused behaves exactly the same as while any other generic element is focused (or no element is focused). This includes even if results are displayed.

While any result focused:

Tab/shift-tab behavior is unmodified. However, a result focused with tab/shift-tab is in exactly the same state as if it were focused with up/down-arrows, so it responds to the same up/down inputs and has the same focus cue.

Entire result list should have a visual focus cue, in addition to the individual focused result. This is to indicate that keyboard behavior is changed. The focus cue on the actual search result is probably the same as hover.

  • Press up to focus the previous result, or the search input, if on the first result. (Focusing the search input should not select all; it should restore the cursor position saved earlier, if available, or else move to end.
    • If the search input is focused via shift-tab, again, just use default browser behavior. This may e.g. select the entire text area. This is intentional. (Using tab/shift-tab treats the input as a normal form element, rather than an input with custom behavior.)
  • Press down to focus the next result. (Pressing down never selects the "OK, I'm done searching now" button. Keyboard navigation via up/down should never land on a "dangerous" action, i.e. holding down moves to the last result, it doesn't focus the dismiss search button.)

Mouse behavior while a result is keyboard-focused:

  • Mouse-entering a result, after e.g. a 75ms delay, moves keyboard focus to the hovered result.
  • Mouse-moving over a result does nothing.
  • Mouse-exiting a result does nothing.
    • The delay on mouse-enter is so that you can swipe the mouse off of the results area (after initially using it to focus a particular element and then, possibly, navigating away w/ keyboard), without accidentally changing keyboard focus because the mouse passed over another result.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant