I think right now if you need that your best bet is to do like toolbar block inline so both sets of arrow keys work (already how radio buttons work).
10.03.2026 18:48
π 0
π 0
π¬ 0
π 0
I think right now if you need that your best bet is to do like toolbar block inline so both sets of arrow keys work (already how radio buttons work).
Yeah grid is just one example of the potential 2d avenues. I think it'll likely end up supporting some CSS layout driven navigation mode.
The 2d navigation cases are more interesting for me, they'll come down the line.
Fwiw I agree to some extent, we should just add the elements themselves. We have listbox already, menu(list) and menubar are being worked on, and I've recently started prototyping toolbar. At that point it's just tabs left, but they'll take time.
I think it could be a useful primitive though.
focusgroup is quite focused on the arrow-key navigation and the aria role stuff is just part of trying to tie it to specific patterns, but there's lots of different parts to these patterns. Too much for one attribute to handle. For example tablists sometimes selection follows focus, sometimes not.
Yeah if you do e.g. <div focusgroup="toolbar"> it gets the toolbar role. Only if the element doesn't have its own semantic role though.
It'll also make child buttons the right role for various behaviours. So for tablists they'll be tabs. Importantly tho it won't add stuff like aria-selected for you
We would like to congratulate @lukewarlow.dev on being appointed by the W3C TAG as an Associate!
The Associate program (tag.w3.org/associates/) was launched a little over a year ago with the goal of helping to extend the TAG's ability to review and influence work.
0.0018
Firefox Android on my Pixel. So it's super human cone cells or you've got bugs to fix π
Can you explain the question a bit more? The focusgroup attribute can set implicit aria roles on the container and in some cases on the children. Pretty much everything else is left up to the consumer still though.
For those who want to test their perception of colour, I made a little game called "What's My JND"
www.keithcirkel.co.uk/whats-my-jnd...
Oooh, nice to see another browser working on this API!
It should obviously not be used as an excuse to not heavily invest in wind, water and solar. But it also shouldn't be excluded as part of our future energy sources.
Countries like Germany closing nuclear plants and going back to coal is such a massive own goal of the greens.
There's been two cases where nuclear energy has caused serious problems and one of them was caused by an incredibly strong earthquake paired with a tsunami. Both involved copious amounts of systemic incompetence too.
It overall is an incredibly good and clean energy source.
Even that one is going to struggle until we get better WPTs for accessibility. At least we can test roles and labels now.
Manual testing is unfortunately the only sure fire way to know. We severely lack in both automated testing of accessibility (for the bits that can be automated), and a data set that reflects this support.
MDNs more granular dataset sometimes might flag issues but often won't.
github.com/w3c/csswg-dr... - I have another semi frequent layout that afaik is just impossible with CSS.
A little over 3 months to go until Web Engines Hackfest 2026, happening June 15β17 in A CoruΓ±a!
If you plan to attend onsite, please register here: forms.gle/7gSwfFebFW7s...
We already have more than 50 people registered: webengineshackfest.org#attendees
Yeah exactly. I don't think it's actually super complex to do, but there's a lot of "tabs" in the wild that aren't actually tabs (in the aria sense) and one historical point of contention has been how do we stop people using tabs for the wrong thing.
No, the proposal is for a new menulist and menubar element, for compat reasons the old one is probably best left alone.
open-ui.org/components/m...
Yes they do provided they're already keyboard focusable, though there's behaviour to handle key conflicts. So the input for example you can arrow into it but then you'll need to tab out and it makes sure there's no part of the focusgroup you're prevented from getting to.
They keep their intrinsic roles. I don't believe toolbar implies any, but tablist for example will set buttons to tab but most other items won't change role. Buttons was a recent change originally anything with its own role kept it, but I believe it was Sarah pointed out buttons really shouldnt.
Yup, menu(list) and menubar are being worked on too. So I think with those 3 it's just tablist left to go! But they all have varying levels of complexity beyond just what focusgroup provides (admittedly toolbar itself is quite simple).
One key difference I hope will be in Safari. They don't make buttons keyboard focusable by default, I'm hoping we can get agreement that inside of a toolbar element they are for the purposes of the arrow key navigation.
Focusgroup right now doesn't affect that behaviour per the spec.
Yeah for the record I fully agree we need to go further with custom elements, e.g. they should be able to be implicitly focusable, popover, draggable, or in this case implicitly a focusgroup. In fact I have an issue open to enable the latter 3.
It's not all that different right now, it's akin to `<div focusgroup="toolbar">`. In fact it's using focusgroup under the hood in my prototype just without spawning the attribute.
But there's potentially some extra things we can do, e.g. stricter key conflict handling.
Gate keepers that let anyone contribute to the standard (whatwg needs no paid membership) and browser code? All of which have open sourced their browser engines for anyone to take and use should they wish. Don't get me wrong they all do a lot of wrongs but native elements aren't being gatekept.
Google? I don't work for Google. I'm also just doing this in my free time as part of the OpenUI group. π€·π»ββοΈ
is simplified to "not to use aria". We can't really expect that to work out if we have a bunch of aria roles with no html solution. Obviously we might disagree here but I think we really should be adding toolbar, menu and menubar, tablist and any others we might be missing.
...attribute which I think is the sort of thing you're asking for. It enables the single tab stop arrow-key keyboard behaviour. That's the heavy lift for browsers, but once we have that I see no reason why we shouldn't be able to make first class elements for these things. First rule of aria is 2/
We add what 1 or 2 new html element every 5 years (I'm ignoring the weird permissions element stuff). That doesn't seem too unreasonable? I agree some stuff (CSS and even JavaScript) does move too fast at times but html is pretty conservative. Fwiw we are doing the primitive that's the focusgroup 1/