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

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?

Start with Accessibility/FocusLandmark/explainer.md, then compare its proposal with the linked ARIA landmark role and focusgroup references. Evaluate the stated keyboard, nested-region, iframe, browser, and accessibility concerns; done means recording concrete feedback or a decision on whether the declarative primitive should proceed.