Meeting minutes
New PR Triage
spectranaut_: PR 2605 from pkr
pkra: just replacing mario's.
spectranaut_: next one is a dependabot PR
… let's assign it to Daniel.
spectranaut_: sarah's we discussed last week.
… 3 reviews. needs ACT review.
New Issue Triage
spectranaut_: 2604 from pkra
pkra: I extracted it from a PR during review. It seemed worthwhile to separate it out.
… but also nothing I think we have language for.
sarah: right. I was surprised at first that it had been removed. but makes sense when collapsed.
Rahim: why not when it's collapsed?
sarah: I think it's unique to combobox. the other's don't have to wire things up like it.
bryan: it might also not be in the DOM.
… but I agree that it's confusing that it's not noted that you need it when it's expanded.
jamesn: can we not add it to the normative language?
… seems like it should say something about being required conditionally.
spectranaut_: I agree. Can someone take it on? Or do we need to agenda it?
sarah: I can look into a PR.
spectranaut_: next one, again from pkra, again extracted from PR. has suggestion so it should be an easy PR.
jacques: you can assign me.
spectranaut_: next one is on the agenda.
… next #2596 from Adam_Page
Adam_Page: I stumbled upon this while writing tests.
… I happened to use a list, and then ran into Firefox adding "bullet".
… this led me to the spec, the change that Firefox is correct but the only browser. So I filed this issue.
… (and there's also a typo)
spectranaut_: sounds good.
bryan: ditto
spectranaut_: next is issue 2594 from giacomo.
giacomo-petri: we discussed this a little bit in another PR.
… I dug into it.
… I hadn't seen Scott's latest comment though.
spectranaut_: can you take it on?
giacomo-petri: yes.
I'll follow up with scott.
WPT Open PRs
spectranaut_: nothing new.
… any old issues we should discuss?
… fyi I have a PR to extend testdrivee to AAMs if anyone wants to take a look.
Deep Dive planning
spectranaut_: no issues
Editorial: Update ARIAMixin to use new [Reflect] extended attribute
pkra: There was ping from Domenic. I wanted to make sure we're ready to land this.
Rahim: I think so. It's fairly simple change.
… I can investigate the other question in my other IDL update.
cyns: Yes, let's merge.
spectranaut_: let's merge.
Scoping focusgroup to scenarios defined by aria roles
Jacques: a few years ago we had the focusgroup proposal. It went to trial in Chrome. It gives a roving tabindex.
… I'm working on a new, scoped proposal.
… this proposal has a couple of different ways.
… either requiring a role or bubbling into a role.
… the whole idea is following the paved cowpaths.
… e.g. menus.
… replacing the usual JS approach with focusgroup.
… I'm looking to understand what this means for ARIA, what problems and benefits.
Rahim: I haven't read it yet but had some questions from just now.
… first, it seems it would need screenreaders to adopt focus mode.
Jacques: yes. If today you end up on a menu using JS, screenreaders work. I'm aiming to make it work the same way with focusgroup.
… tying it to role hopefully helps.
Rahim: right. screenreaders would still need to go into a focus-mode kind-of state.
Jacques: my hope is to make it work just like the JS situation today
<spectranaut_> pkra: rahim touched on most of this, I remember there was a thread on the original proposal about AT interaction, the only point that I chimed in or scott did, mobile AT has me worried, because there is no focus mode -- how much of the previous discusions have you dealt with?
Jacques: I looked at the history and tried to address it. I might have missed something but will double check. Thank you.
keithamus: one point of pushback might be that html features don't really interact with ARIA feature.
… maybe focusgroup might influence role rather than the other way around.
<Jacques> Syntax: focusgroup="toolbar wrap" (role token required; may omit separate role= attribute).
Jacques: yes. I'm leaning towards focusgroup taking in the role and informing aria. authors could still override but this might be a way around this.
keithamus: ok. that could work. It might help to avoid proliferation of keywords since you have roles.
sarah: seconding keith. I would like to see a scope mechanism. Maybe another attribute would be useful.
… there's also all the roles of the children. E.g. type=tablist and all focusable children become tabs.
… if it wasn't directly tied to role, authors could still override it but also benefits.
Brett: I really need to read it carefully. From a screenreader point of view, we're looking at what control you're interacting with decides if we put users in focus mode. Maybe we don't care if the user agent would control focus.
<cyns> +1 to reading the proposal! I like the idea
Jacques: thank you. If screenreaders find this is causing problems, then that's a problem for the proposal.
Rahim: is there cross-over with reading-flow.
… it seems there might be overlap.
Jacques: this proposal does not allow authors to change the ordering. There might be some overlap if combining this with reading-flow. I'll have to give that some thought.
Rahim: also, it seems it would ignore positive tabindex values. That would be the case?
Jacques: I think right now it would cause the highest tabindex to work initially but then stay in the section.
spectranaut_: anyone else? Or use our time to read the proposal?
Jacques: thanks everyone for the feedback.