[focuslandmark] No declarative way to move keyboard focus between major page regions

[benbeaudry]

Rich web apps are built from major regions — a ribbon, a navigation pane, a document canvas, a chat list, a composer, an assistant sidebar — much like native apps. Users want to jump between these regions from the keyboard without Tab-ing through every control in between. This is one of the most common accessibility and productivity requests for web apps, yet the web has no primitive for it.

Today the paradigm is missing:

• Sequential navigation (Tab) spans the whole page but visits every control — exactly what users want to skip here.
• Directional navigation (focusgroup) moves within one widget.
• Landmark navigation — moving between regions — has no declarative equivalent.

Native platforms do this routinely (e.g. F6 / Shift+F6 on Windows), and browsers already use it for their own chrome, but it stops at the edge of web content. So every app that wants it hand-rolls a solution: picking a key that may clash with the browser or nested apps, maintaining an ordered region list and a "current region" pointer, deciding where focus lands in each region, and re-implementing all of it across iframes. The result is inconsistent or absent behavior across sites, and no shared model between browser UI and page content.

Because this problem is common across web apps, it seems worth solving at the platform level so behavior, default accessibility, and interoperability come from the browser rather than per-site script.

I've drafted an explainer proposing a declarative HTML primitive, inspired by ARIA landmark role and focusgroup (placeholder name focuslandmark) for this: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/FocusLandmark/explainer.md.

This is an issue with an obvious fix on Windows (tying it to the OS-wide feature landmark navigation key F6), and it looks like some people at Apple are also looking into solving this problem: https://bsky.app/profile/marinaaisa.com/post/3moiffbnotc23.

I'd like your thoughts. Is this a problem others agree on? What ideas do you have to solve it?

[smhigley]

I think Carolyn Macleod was looking into this a long time ago too, and wrote this + the linked browser issues: https://webwewant.fyi/wants/5f24adc28dfea402c3830218/

hopefully helpful 😊

[tombrunet]

I have an exploration of this implemented here (though not necessarily tied to landmarks):
https://tombrunet.github.io/carbon-labs-storybook/index.html?path=/docs/components-focusregion--overview

One issue I ran into is that users who expect to be able to tab through everything and don't know about F6, it makes it difficult to find all of the content. And, F6 on modern keyboards is trickier to use than on older keyboards. I chose to go with not restricting tab to the 'frame', but still allowing F6 to bookmark focus and jump to the next region.

Labs PR: carbon-design-system/carbon-labs#1301

[adampage]

Wow, @benbeaudry, excellent. I made a similar quick & dirty proof-of-concept a few years back. I chose a careless keystroke combination at the time, but also prototyped a “last focused” behavior between regions. Excited to read your proposal.

[benbeaudry]

@tombrunet, @adampage, awesome!

I just played around with both of your examples and my proposal would work the same way (with a couple of minor differences due to being built directly in the browser: regions in the UA (address bar, favorites, tab bar, sidebar, etc.) would be included in the list of regions, and it could work across nested frames. Very excited that we all converged towards the same experience.

[jscholes]

@tombrunet When you say:

F6 on modern keyboards is trickier to use than on older keyboards.

... are you referring to the increased usage of laptop keyboards and frequent default repurposing of F-keys bound to actions (like play/pause and wi-fi toggling)? Or something else?

[tombrunet]

Yes. For instance, I'm on a Mac at the moment and if I hit F6, it turns on Do Not Disturb. I have to press Fn+F6 and Fn+Shift+F6. I doubt there's a better key available, but just seems like triggering F6 requires extra modifier keys - and how that works isn't consistent across machines.

[jscholes]

@tombrunet Makes sense. There is a history of people locking those keys to their original, non-utility functions particularly when they need to use them frequently.

For example, I'm on Windows and Alt+F4 to close a window is a keystroke I use hundreds of times per day. Likewise NVDA+F12 to check the time, F11/F12 to review the speech history in my screen reader, and the list goes on. For me, having them act directly as F1 through F12 by default is the only practical option.

This practice isn't universal (or universally known about) and will vary a lot based on specific needs and access technology usage. But it might be worth factoring in.

[benbeaudry]

@tombrunet If I understand your point correctly, you're saying that's an extra key and it's even more things to remember for the user. I agree with you, and would like to clarify three things that are worth pointing out, imo:

1. As both a macOS and Windows user, I got used to this macOS-specific behavior of having to press the Fn key to reach any function key. It makes sense; it's OS-wide, and I'm used to it.
2. This proposal doesn't suggest making F6 (or any function key) the standardized key; instead, it leaves it up to the UA and the platform to define their own key. On Windows, because this is a well-defined feature already implemented across apps (but the web platform), I suggest reusing the same shortcut to the web platform as it feels like a natural extension of the same OS-level feature. As far as I know, macOS doesn't have this keyboard-first landmark navigation feature natively across apps (I believe they support it with VoiceOver, though), but if they were to implement it
   1. the web platform would be have everything ready for it to "just work" with this proposal (with the key of their choosing), and
   2. browsers like Microsoft Edge, Chrome, and Firefox could implement a UA-only feature with the key binding of choosing without being blocked by the OS. The key would be left to the UA to determine, and expose it to the user
   3. Personally would love to see macOS adopt such a highly requested feature at the OS-level, but this is out-of-scope to this web platform specific problem we're trying to solve.
3. To play devil's advocate for the Fn+F6/Fn+Shift+F6 on macOS (again, not recommending using this specific shortcut for this proposed feature), it would still be an improvement if all websites had this feature exposed with this specific key combo instead of having many websites not support the feature at all or, worse, support it with different shortcuts for every domain (like is the case today).