Every custom listbox, tablist, menu and toolbar you have ever shipped has come with the same hidden JavaScript bill. The keyboard behaviour a native <select> gets for free, arrow keys moving between options, Home and End jumping to the ends, Tab leaving the widget entirely, you have written yourself, every time, and hoped nothing regressed.
Per Adrian Roselli's write-up, Chrome 150 has landed an HTML attribute that tries to hand that job to the browser. focusgroup puts arrow-key roving focus inside a composite widget on the platform. Roselli has published a set of demos exercising it, and per the source there is no scripting in any of them.
The keyboard tax composite widgets keep paying
The shape of the pattern is always the same. One tab stop for the widget as a whole. Arrow keys move focus among its options. Home and End jump to the extremes. Screen-reader users rely on it. Sighted keyboard users rely on it. And, in practice, every project rebuilds it in JavaScript, ships bugs into it, and eventually rewrites it.
That is the tax focusgroup is trying to remove. You put the attribute on the container and the browser does the roving. Focus moves inside on arrows. Tab moves out. No listener, no counter, no keyboard-trap regression to chase in the next sprint.
