Lea: I think it's a first that focus can be controlled by CSS this way. No precedent. Not sure how it interacts with the HTML attribute.

Peter: something similar about navigation... TV set top box uses case...

Lea: i think it's an amazing idea - but departure from precedent. Says CSS values will override HTML values if they conflict. Like presentation attributes in SVG.

Dan: is this primarily or tangientally an accessibility thing?

Lea: I think it's an accessibility and usability thing

Dan: should we get accessibility people to look at it?

Lea: Can't hurt

Dan: noting a11y community feedback - nice to see.

Rossen: assume it's going to evolve through appropriate WGs..

Lea: corresponding attribute to element internals? how can componenets have it by default? Can see many use cases

Rossen: absolutely. Any type of list control. Good question. The example (19) is more or less exactly that.

Dan: this explainer is very developer mindset focussed. Not stating things in terms of the user need. What we're talking about is an accessibility issue, so what accessibility problem are we trying to solve. Is that spelled out?

Rossen: in the goals

Lea: not trying to solve a11y per se, but a developer pain point about accessible interfaces. Helps accessibility indirectly.

Rossen: and connecting the other end with ATs so they can build on top of this. No accessibility solution that don't includde 3 parties - developers, engines, and the screen reader / etc technologies. Unless all of these things work together you don't have an accessible solution. Which one of these are you asking about?

Dan: trying to parse the user need from the explainer. Could be better spelled out.

Lea: I'd like to see a response to the point in this comment - seems like a reasonable question.

Dan: can you amplify the question?

Lea: yeah

Dan: we've had feedback - added material around a11y in explainer. This is in response to Lea's feedback and could be addressed. Lea should review.

Dan: their PR 550

Lea: any movement?

Dan: not since June. A PR merged in mid June which is about a11y.

Lea: I don't have the a11y knowledge to evaluate how serious this concern is.

Dan: did Travis's comment address your issue? Not really

Lea: don't think it should be a blocker. Just a matter of doing it. the other thing is this person who raised this concern and I'm not sure how serious it is.

Dan: we could bring in external help?

Rossen: the overall issue that Paul raised was with some of the.. one of the examples which was addressed by the api itself and the ability to navigate through focus groups. The way I read this comment is I believe he was misled by the example in believing that the tab index in combination with focusgroup is going to be an issue. Which explicitly I think somewhere in the explainer.. section 6 focusgroup concept.. talking about overall interaction between tab index and how that extends to handling of focusgroup and focus. So generally speaking focus mangaement and focus itself is a fairly loaded issue on its own. I can help if I spend some time. Distanced myself since I was involved in the initial design, a couple of years ago. I don't see the concern from Paul as being something that should block progress.

Dan: close satisfied?

Lea: [comments] - can reiterate the thing about element internals? Anything about Paul's point?

Dan: could say please engage with the accessibility community to ensure they look at this. [APA]

Rossen: pretty sure they already have. Done in part with the help of the community. Not in a vacuum. But fine to remind them.

Agree to close

punt to plenary