Post

Initial prototype of a `<toolbar>` element is coming along. Largely piggybacks off the focusgroup code so it's actually quite simple to do. Lots to discuss and tweak before it's finished but got to start somewhere.

That looks like a use case for a custom element. What’s different with this native new element?

It's built into the browser? Handling the keyboard behaviour automatically is a pretty big win over using a JS library for it, imo. Focusgroup has actually quite complex conflict handling for if you say put an input inside a toolbar. Doing this in a custom element would be quite a pain.

ok... but that is not scalable at all if we need to convince browser vendors for every such use case. I'm sure some enjoy the control that gives them but damn... Looks like the primitives need fixing instead?

...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/

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.

Just want to say I agree with this so much. Not everyone knows how to build custom elements. And the main reason ARIA exists is to provide semantics for things that don't exist in HTML. But, as others have said before me: ARIA should be thought of as a temporary solution.