While I do agree with the latter 2 points, (can't multi-jump, hard to memorize), the assertion
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);
Isn't quite true - all HTML elements support the "tabindex" attribute[0], which can be used to set the tab order of a page's HTML elements.
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.
Better than tabindex is assigning semantically-sound access keys (alt+shift+some-letter-that-makes-sense-for-the-task).
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).
Looks cool but I don't like the idea of pushing a library on the user when they would most likely not use that kind of navigation anyway. Ever wonder why your browser is using 16Gb of RAM? This is why.
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.
Super cool. As a note, try selecting "Areas" for a hierarchical view
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")
This is really good! So good that it ought to be implemented in browsers in my opinion, probably as a set of additional `aria-*` attributes.
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.
> So good that it ought to be implemented in browsers in my opinion
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.
Really neat. My biggest gripe is that there's a lot of good, neat, interesting semantic data you're marking up the JSX with, about Area and Anchor, and none of that information makes it into the rendered HTML. I'd love to just see something as basic as `data-area` attributes on things that are areas, to make this internal context this cool library makes a bit visible, knowable, & accessible, to whomever might want to explore it.
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.
Engineer who specializes in digital accessibility here.
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.
(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:
This used to be one of my favorite Google UI Engineer interview questions - how to implement something like this as a content script.
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?
I've been wanting something like that for a long time. Eye tracking + a simple keyboard shortcut to trigger a click so I can select anything across the entire system instantly without having to take my hands off the keyboard. So far though I haven't been able to find any decent out-of-the-box solutions for that without any major drawbacks.
Eye-tracking is an underrated user input method in my opinion. I'm hoping eventually VR/AR will make it mainstream.
No, you blink all the time. There have been many, many of these things tried and they all suck quite frankly. It’s best to find some other way to confirm a click, or perform a scroll, etc.
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.
Until your hands start hurting like the person who I mentioned. I was trying to discuss solving the general problem. Some people also suffer when using a keyboard
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.
You might want to see this pre alpha experiment for typing in keyboardless XR. For me these days when I hear 'Spatial' I think 3D systems with ray tracing controllers and hand tracking. You can also follow its dev on Twitter for more details.
Ah, yes, hijacking the arrow keys. So it breaks both arrow-key scrolling and selecting a previous input in a text field—or selecting autocompletion results, or perhaps other ‘rich’ input functions.
It is very intuitive but slightly buggy on Safari 15. The highlight will land half-way between elements but on the next keypress it will then correctly align itself with another element.
intesting.
btw i tried the preview https://spatial-keyboard-navigation.vercel.app/ .. the 3 checkboxes at bottom left don't play well with up-down arrows , and dont show the focus when on ;
and the tab-keyed focus is not shown either..
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]:
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...