Spatial Keyboard Navigation(danilowoz.com)
danilowoz.com
Spatial Keyboard Navigation
https://danilowoz.com/blog/spatial-keyboard-navigation
22 comments
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).
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
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
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.
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")
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.
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.
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.
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.
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
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
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?
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?
Looks great. I wish I could use keyboard navigation more because my wrist hurts from mouse, and mouse pointer is kinda hard to target.
Is it possible to implement this thing as browser extension?
Is it possible to implement this thing as browser extension?
I think you'll find this presentation by Emily Shea on voice driven development to be intriguing. https://www.youtube.com/watch?v=YKuRkGkf5HU
aside, novel HIDs are IMO a huge market gap that I'd really like to invest time in if anyone wants to chat.
aside, novel HIDs are IMO a huge market gap that I'd really like to invest time in if anyone wants to chat.
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.
[1] http://www.lexting.com/
[1] http://www.lexting.com/
I use Vimium's hint navigation. Works great for most sites.
Why not wish for eye tracking so we could simply look at something? Then a subtle Soli gesture to select.
https://atap.google.com/soli/
I always think of this blog where the person had to use their nose because their hands were in pain.
http://www.looknohands.me/
Discussion from 7 years ago:
https://news.ycombinator.com/item?id=8805053
https://atap.google.com/soli/
I always think of this blog where the person had to use their nose because their hands were in pain.
http://www.looknohands.me/
Discussion from 7 years ago:
https://news.ycombinator.com/item?id=8805053
Haha, eye only interface would be great. But why do I need Soli for it, wouldn’t webcam-based eye-tracking with one-eye blink for a click be enough?
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.
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
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.
Eye-tracking is an underrated user input method in my opinion. I'm hoping eventually VR/AR will make it mainstream.
Try vimium, which is probably fast (although I usually still prefer the touchpad). This is what it looks like: https://user-images.githubusercontent.com/2781117/28320939-f...
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.
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.
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..
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]:
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...