Meeting minutes
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: html-aam 604. li outside list
pkra: it would be great if implementors could implement this change
spectranaut_: right. looks like we have a bunch of these.
scotto: was wondering about this. Conversation with chrome engineer, that they do look at WPTs and track failing ones to deal with.
… but of course the WPT has not been merged either.
… still, it would be good if we only need one.
… WPT or browser bugs.
keithamus: just to say: there's a lot of WPTs and a lot of failure and thus a lot of noise for teams, at least for us.
… so it's worth filing a separate issue to make sure it's surfaced with the right team
scotto: thanks for clarifying!
spectranaut_: if you're interested, we could set up a deep dive for people who want to learn filing browser bugs.
… though I wonder why the WPT test isn't merged.
cyns: maybe we should have separate processes for different browsers.
keithamus: I suspect they're similar though.
dgrogan: we have the same firehose problem as firefox. If you can find the automated WPT bugs and ping it, that would be sufficient.
spectranaut_: I'll look into landing the WPT PR.
keithamus: I think WebKit doesn't have automatic bugs for WPT failures.
spectranaut_: aria 2767. listbox and accname
scotto: listboxes as popups often don't have accessible names. I haven't seen anyone being impacted by this. I don't think testing flags it since combobox names cover it. Conversations with other developers made me wonder if this requirement should be more nuanced.
giacomo-petri: to echo what scotto said. Our tool triggers an error for this kind of scenario and I agree with Scott that this change would negatively impact users.
scotto: I'm not sure how this works from the automatic table generation code in the spec. so maybe not a great first issue.
pkra: there's a wider issue on handling more nuanced requirements in the automation. I think it's a good first issue in that we editors should work out the automation.
… I'll tag the issue that reflects this.
giacomo-petri: just fyi, I think the suggestion role and separator are cases.
mattking: I'm wondering if this kind of situation should also look into accname, i.e., whether this should affect calculation.
melsumner: I can take it on.
bryan: me too.
spectranaut_: next up css-aam 17.
aardrian: I just wanted to flag it quickly so it's not lost.
spectranaut_: should we agenda it?
aardrian: I'm not sure anymore.
… but I assigned myself to update.
spectranaut_: great.
… next graphics-aria 14
pkra: I just wanted to put this down. inspired by recent svg-aam text discussions and longtime on my mind.
cyns: assign to me so we can track as well.
spectranaut_: next aria 2762
pkra: it's a bit of a mismatch. Definition doesn't suggest any specific way to connect to term. Term suggest something. We should clarify, probably a good first issue.
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: just one from peter
pkra: still a draft. I'm working on it.
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: nothing new.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
ARIA in HTML for revised recommendation, please have your AC reps vote
spectranaut_: just a reminder to please ask your AC rep to vote.
CSS scroll-marker-group modes && WAI-ARIA patterns
<github-bot> I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/aria w3c/aria-common w3c/core-aam w3c/accname w3c/html-aam.
daniil: to recap, CSS scroll-markers were introduced, in particular for native carousels.
… this is our update after feedback from the ARIA WG
… in my explainer I compared the two modes for scroll-marker-groups.
… the first one is tab mode. the second links mode.
… I would suggest to go through the explainer a bit.
… or wait until people have read it?
dgrogan: could you live share some demos perhaps?
daniil: yes. First one is tabs mode.
… one page of the carousel is one tab. Only the active tab is present in the acc tree.
… this was one change - browsers should now auto-hide it.
… here's a codepen demo
… I can tab to get to the first marker. then left/right arrows moves through the tabs.
… in the a11y tree you can see that only the active tab is in the tree.
… when we're at the marker, we go from the marker to content.
… but another tab won't take you to the next tab but out of the group.
… the second one is links mode
… in this mode, every scroll marker is a tab stop. They act like a focusgroup.
… another codepen demo
… we go to the first link. Tab moves me through the links.
… activation moves me to the content.
… just to recap, we discussed aria-current a while back and it's out of scope for this explainer.
spectranaut_: thank you.
mattking: I will need to read the explainer but it sounds like the first case is very similar to tabpanel behavior so I hope we can align there.
<Siri> +1 to Matt
daniil: we followed the tabbed carousel pattern.
mattking: great.
daniil: the links case is from the landmark navigation pattern.
cyns: there was a proposal a few years back from Google on a customized tab panel.
… is this a continuation of that?
daniil: I don't know but don't think so. This sounds like HTML but here we are talking about CSS
scotto: I think it's definitely different.
… it sounds like a lot of the feedback Sarah H, Sara S, myself and others provided is being considered.
… I would suggest to please update the codepen to include focusable content. Otherwise it's not as clear what the keyboard behavior would be.
… it will take me a while to take a look.
mattking: I'd second that. Also something before and after to make it easier for AT users.
daniil: thanks, will do.
<sakhapov> Rob's examples - https://
spectranaut_: it would be great if many people could take a look.
<cyns> I think this is the proposal I was talking about https://
spectranaut_: do people know how to take a look? E.g. get chrome canary and activate experimental features.
<dgrogan> chrome:://flags
<dgrogan> oops. chrome://
<sakhapov> chrome://
mattking: yes more details for testing would be great. Also in the issue itsef.
spectranaut_: right. that would be good.
siri: regarding link mode. tab mode makes sense. But also in the linked mode arrow keys is the expected way?
daniil: for links you just tab through them.
siri: but in the example I thought I had to
daniil: for me arrow navigation doesn't work.
siri: curious, it's different for me. I'll look into it.
Updates to aside element
<github-bot> I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/aria w3c/aria-common w3c/core-aam w3c/accname w3c/html-aam.
spectranaut_: there was a recent comment from APG putting it on the agenda.
Daniel: from APG user research, chrome and firefox mark aside as complimentary in header and footer. But spec says only main and body, unless named.
… we should either match implementations or file bugs.
spectranaut_: this is testable already, right?
scotto: there are tests from 2023.
mattking: I don't think we need to re-discuss. Browsers are just not doing it.
scotto: looking through the tests from 2021. In 2023 James Craig commented on updated tests.
… there's a lingering PR of mine that just wasn't merged.
… due to the implementation mismatch.
spectranaut_: I'll look at WPT tests and follow up - unless someone else wants to.
mattking: sounds good. Daniel?
Daniel: yes. It sounds good to update tests to get things moving.
mattking: we have a PR in APG to say the same thing that html-aam says. But then we noticed the discrepancies and thus wanted to clarify.
… which brings us back to the start of the meeting.
spectranaut_: agreed.