Jacques Newman

Noting related issue: https://github.com/openui/open-ui/issues/1008 I'll add a section on how this interacts with scrolling to the explainer soon, but here are my general thoughts, let me know your thoughts. First,...

We would like to discuss moving this to [stage 2 (iteration)](https://whatwg.org/stages#stage2) Entry Criteria for stage 2: * [x] _A draft specification for the [Contribution](https://whatwg.org/ipr-policy#21-contribution)_: **https://github.com/whatwg/html/pull/11723** * [ ] _Consensus that...

+1 this will "just work". `focusgroup` will consider all focusable elements within the focusgroup's scope as a focusgroup item, including shadow trees. If you as the developer didn't want this,...

+1 to @gfellerph's explanation, beat me to it!

Hi folks, the focusgroup explainer has evolved since this was last visited, and I recently created a new, "Scoped" version of that explainer that takes all of these advancements and...

>How would an initial focus entry element behave if another candidate had a positive tabindex? If the resolution to https://github.com/openui/open-ui/issues/1311 is positive, that would be a nice solution, otherwise one...

>If I’ve got this right: I can add tabindex="-1" to the parent of some focusable elements, and those elements can still be part of a focusgroup. I hadn't thought about...

> Wouldn't it be more intuitive if Tab moved focus to the next sequentially focusable element, including the _Guaranteed Tab Stop_? That sounds right to me, realizing now that my...

>having the tab stop be different when navigating forward vs. backward just seems like a straightforward a11y error, I can't think of a use case for it. I don't think...

> This, to me, sounds like a known tabster bug and not desired behavior (and is more or less what I'd want to prevent 😅): > > > When focus...