Spatial Keyboard Navigation
danilowoz.com
danilowoz.com
It follows the order of the DOM elements and not the visual position of these elements on the page, which means that it uses the HTML structure (not user-friendly), but it should go after the layout position (spatial position);
That being said, using "tabindex" (or having an out-of-order page structure) can cause accessibility problems for those using screen-readers and related programs.
From [0]:
Warning: Avoid using tabindex values greater than 0. Doing so makes it difficult for people who rely on assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.
For example on Wikipedia (and in MediaWiki in general), Alt+Shift+F is search (I guess F is for Find; S is already taken by Save anyway, for people who edit).
There's a lot of them, though most of them immediately navigate you rather than focus an element - https://meta.wikimedia.org/wiki/Help:Keyboard_shortcuts
If the user is already using the keyboard to navigate, it would be better for them to install an extension like Vimium (which I think is vastly superior because it affects the whole browser.)
With this navigation I would potentially have to do more than 10 key presses to reach what I am looking for and with Vimium I have to press at most 3 no matter where on the page I want to go.
I noticed a glitch in the demo. The "options" area, when only "animated" is selected, thinks that the three checkboxes are not vertically aligned (jumps from "animated" to "strict area", skipping "Areas" when pressing up / down, need to press "right" to get to "Areas")
In line with other common conventions, I'd also like to see Ctrl+Arrow to move between areas, home/end to move to the beginning/end of the current area, etc.
Vivaldi browser has had a similar form of spatial navigation for the longest while, which is the Chromium-based spiritual successor to Opera classic (using the Presto engine) which also had it.
Is very useful for navigating forum topics via keyboard and other dense lists of links across different columns/rows where one wants to jump around in a visual order manner.
In a more WebComponent-ified world, I'd love to see these DOM components have left/right/up/down methods, that would return the components on it's sides.
I wanted to clear up a few misconceptions on this point:
"""There is no easy way to jump long distances in the interface: TAB key navigation obligates you to go through all elements between your starting point and the target point;"""
1. TAB key navigation obligates you to go through all elements
Tab actually should behave as the key to enter and exit widgets. Yes some widgets are a single item, like buttons and links, but for more complex widgets you should be using the Arrow keys to navigate.
For example: Example: Tabs - https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-... Example: Dropdown Menu - https://www.w3.org/TR/2019/NOTE-wai-aria-practices-1.1-20190...
(Tip: Shift + Tab to move focus backwards on a page.)
Also pay attention to what happened when you move focus to the second tab and then move away from the Widget and then come back to it. You refocus to the previously active element, not the first on. This is called a "Roving Tabindex" a very common pattern.
This solves the problem of:
A. Having to press TAB a lot to move through a page
B. Making it clear when you enter and exit a widget
These specs/keyboard design patterns have existed for a long time, but most folks only focus on the WCAG which only talks about keyboard focus so folks think everything needs to be "tabable".
2. Tab is the only way to navigate with the keyboard
Nope. Most folks who use screen readers actually navigate by headings and page landmarks. Unfortunately that navigation isn't on by default but there does exist some extensions that can turn those on for everyone:
Extension: https://chrome.google.com/webstore/detail/landmark-navigatio... Code: https://github.com/matatk/landmarks
One of the fun "get away from math and into experience" bonus parts of the question was about how to deal with ambiguity - for example, if your elements are laid out like the 5 on a dice, and you focused on the middle element, which do you pick when you press left or right? What if you'd previously come from one of those elements?
Is it possible to implement this thing as browser extension?
I always think of this blog where the person had to use their nose because their hands were in pain.
Discussion from 7 years ago:
Webcams don’t have enough resolution to be so precise, need really good models to track your head and estimate pose, etc. You also aren’t illuminating anything with a web cam so dark eyes become difficult, glasses non-linearly, warp the eyeball, and a host of other problems. Webcam based approaches usually get very very rough areas that move around like crazy (very noisy).
Essentially the best way to do it is to have something mounted to your face that’s purpose built. There are external eye trackers that are attached to monitors that can do pretty well, but are usually very expensive. The cheaper ones aimed at gamers are quite inaccurate.
Eye-tracking is an underrated user input method in my opinion. I'm hoping eventually VR/AR will make it mainstream.
It's one keypress to get the hints, then usually two to select the element, whereas tab-navigation is 1/4 the number of elements on the page (if you do shift+tab whenever it's shorter) and this Manhattan-style keyboard navigation is 2 x sqrt(# elements), if I'm not mistaken.
Here's what I thought just reading the title: press a key, and the elements are spacially mapped onto all keyboard keys (except ESC). Then, hit the key in the general vicinity. If there's too much and you are likely to miss, zoom into the specific area and repeat.
That's really equivalent to the vimium method, but a bit more visually intuitive.
aside, novel HIDs are IMO a huge market gap that I'd really like to invest time in if anyone wants to chat.