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:
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