More intuitive use of TAB key in navigating

MalcolmCook

Using TAB to " Cycle forward between navigation tabs" is non-intuitive - I think most users will expect TAB to cycle between targets on current page (the search results page) - indeed as happens on kagifeedback.org. Consider using [ and ] to navigate the search panels - or maybe digits: 1: web 2: Images 3: Videos, etc

Vlad

Agreed Tab is inadequate.

We should change Tab to "Open control center". Remove the three other shortcuts tab, shift tab, shift ~

MalcolmCook

Vlad We should change Tab to "Open control center"

I disagree. I think you should not steal TAB which should be preserved for navigating between on-screen controls. You could allow tabbing onto the "send feedback" and "control center" controls, from where ENTER should active them. Find another key to open the control center.

You could borrow from gmail, who IMHO quite effectively use back-quote and shift-back-quote to navigate between "inbox tabs", as pictured.

YMMV 😉

Seirdy

Vlad Predictable tab behavior is a critical part of accessibility. The WCAG's most basic "A" level requires that all elements are keyboard-focusable, and users who rely on keyboard input expect this to be done through the "tab" key.

I'd recommend letting the tab key work the way it does in other search engines.

z64

We discussed this and will be removing our binding of tab for the reasons mentioned. The only question is what to replace it with.

Personall I like [ and ] that the OP suggested.

Seirdy

Just wanted to cycle back on this on more time: "Tab" should work normally, i.e. it should cycle through all focusable elements on the page. This is really important for accessibility; users who can't use pointing devices or touchscreens depend on this in order to be able to use a page at all.

Furthermore, there should be a mechanism readily available to turn these custom binds on or off, so they don't conflict with the user's own keybinds for navigating. For reference, Searx makes vim-like navigation opt-in. I think making these opt-in is a good move, since users are supposed to use Kagi signed-in with customizations applied.

I think some a11y conformance is an important milestone to reach before exiting beta, at least WCAG A (though sites ought to reach AA).

z64

Seirdy Yes, as mentioned removing any binding of Tab is still on our to-do, for the reasons you mentioned 👍️

We also have an option in settings for disabling extended keybinds. Although I don't recall offhand what this includes.

Seirdy

z64 Thanks for the update. Removing tab is a good start, though a proper audit of Tab-selectable elements would be welcome. Using Firefox's accessibility tree (Shift+F12) or Chromium's experimental equivalent should help; many clickable elements either aren't focusable or don't display a focus indicator (typically with a border). Some ARIA roles or semantic HTML should fix this.