Meeting minutes
New Issue Triage
spectranaut_: We should agenda this.
Daniel: comfortable with that.
spectranaut_ This seems like something we should also agenda.
scott: Agreed
jamesn: Would a really simple PR help for that agenda item?
scott: Either works.
spectranaut_: Also from Scott, larger conversation.
Scott: Agenda, but maybe for later this meeting.
jamesn: I'll aenda for this meeting.
spectranaut_: Mel already made a PR, so moving on.
Specrtranaut_: There is already a PR for this, will discuss then.
rahim: Yes, that works, Several issues related.
Specrtranaut_: Assigning to Rahim.
spectranaut_: Already agendad.
spectranaut_: w3c/
spectranaut_: Is this something to talk about? We don't have a place for it yet. CSS-AAM backlog?
pkra: Sure?
pkra: We should at least document it.
jamesn: Dangerous to change behavior from what it is today, agree it should be documented.
Rahim: Assign it to me to investigate what browsers do today.
melsummer: Assign me too, please. I'd like to help document and reasons why.
jamesn: I would love to see a way to address this for keyboard users, since mouse users already often get a hover.
New PR Triage
spectranaut_: Editorial change
melsumner: Can we make sure it's editorial? I don't want to mess up tests.
spectranaut_: Yep.
spectranaut_: Another editorial.
pkra: Just needs sign-off.
<np-at> RE line-clamp There’s also text resize behavior which should be mentioned. Line clamp inherently increases truncation when scaling is increased… which is not obvious to many developers
jamesn: I'll review it.
spectranaut_: Another editorial, good to merge.
spectranaut_: Another editorial, good to merge?
pkra: Yes.
spectranaut_: Another editorial
pkra: DPUB, minor editorial.
daniel: I can review it.
spectranaut_: Another editorial for accName.
spectranaut_: Looks like follow-up to accName convo.
Rahim: Would like Brian, Scott, Melanie to look and approve.
scott: I think there is probably a bigger discussion about the bigger issue.
scott: Around how accName is calculated (DOM nodes, accTree, etc). There are other tangents to explore.
jamesn: accName doesn't apply in this issue, right?
scott: That's the concern, it applies for general steps but also identifying what wins in conflicts and how host language factors.
scott: Look at the specs with more specific rules since it can't be called out in a general algorithm.
jamesn: And those specs point to accName for specific steps, otherwise you stay in the spec.
spectranaut_: Is there an issue for this?
melsumner: Yes, issue 250 in accName.
scott: I think this issue will resolve it as long as it is a more general note.
spectranaut_: Thank you for grammar fixes. Reviewers?
janefulton: I'll take it.
spectranaut_: This has a lot of reviwers.
Rahim: I recreated the work from the old PR. Thanks to keithamus for taking all the time explaining the differences.
Rahim: Switch this to draft.
<aardrian> s/Pete/Keith/
spectranaut_: This closes an issue from a few meetings ago.
pkra: Yeah, it would be good to have another set of eyes since giacomo-petri did all the work.
pkra: This would close another issue to add a term for accessibility ancestor.
melsumner: I'll review.
pkra: The trouble is a scoping statement to allow groups if they contain menu items.
<np-at> I'd be interested
pkra: You don't want to allow nested groups with menu items also without a menu somewhere.
giacomo-petri: You have to check both directions.
scott: Add me as a reviewer.
Matt_King: Add me as a reviewer.
<scott> actually, since this is becoming a bit of a party - i probably don't need to review anymore
WPT Open PRs
spectranaut_: Can we write tests for parent/child items and intervening groups?
aardrian: This is the current agenda item (WPT)
giacomo-petri: Yes, but there are some roles that complicate it (paraphrased).
Deep Dive planning
spectranaut_: Discussed last week, removing label. Can someone add a summary?
jamesn: I sent it to you.
spectranaut_: I'll check it and paste it.
Investigate changing ID-based WAI-ARIA value types due to referenceTarget
spectranaut_: This is editorial?
Rahim: This addition to HTML spec allows an ID association that crosses shadow root boundaries.
Rahim: The HTML spec is not formalizing the ID association.
Rahim: So with ARIA attributes, it is an element reference.
Rahim: With multiple IDREFs, its a "set of element references."
Rahim: So is this more than editorial since it thinks about the types of attributes an ARIA attribute can take.
Rahim: Thinking if ARIA should update accordingly now that HTML is add reference target.
Rahim: Perhaps it is just editorial.
spectranaut_: I think it's editorial, but since HTML spec changes haven't landed maybe we should un-agenda this for now. I'll add myself to help track it.
Rahim: Alice Boxhall mentioned there might be an impact on the AAMs as well.
spectranaut_: Yep, part of why I want to track this.
Matt_King: Does this have impacts on ARIA and it being host language agnostic?
Rahim: Good reminder ARIA needs to be host language independent, which is what spectranaut_ was referncing.
spectranaut_: Now there may be changes, like if aria-activedescendant would point to shadow root not versus the node deeper in the Shadow DOM.
aardrian: Next time -- aria-controls!
aardrian: For minuting!
Document interop of misspelled aria-labeledby and its conflict resolution
spectranaut_: There's been an update from keithamus
keithamus: Looking at deprecating the one L variant.
keithamus: Looking to see how it's being used in conjunction with misspelled and spelled variant.
keithamus: We'll continue to track deprecation and remove it in Chrome.
spectranaut_: No objections.
Stale PR Processing
spectranaut_: Does anyone have a PR they have open they want us to look at and remind us to review? That's the point of this agenda item.
spectranaut_: We have 86 open PRs.
Rahim: I have one.
spectranaut_: Oh, you responded to my questions, Thank you, I will review today.
Rahim: Another.
jamesn: I'll look at it. Right now.
Rahim: Yeah, ok, one more.
Rahim: Thank you melsumner and scott for helping.
spectranaut_: Has three other requested reviewers.
w3c/aria#2496
spectranaut_: CSS is coming up with stuff and we need to keep an eye on it?
scott: Yeah, two new significant features.
scott: One is CSS carousels. Which we discussed a bit at TPAC for how things might be exposed, how to map the elements created by CSS.
scott: But can't recall where it came back to group for discussion.
scott: We don't have a CSS-AAM.
scott: But there appears to be no rep from ARIA acting as a point person.
scott: The CSS spec is silent on how they should be mapped, it at all. But there is no CSS-AAM to do it.
scott: We need someone on point to bring consensus from ARIAWG. It can't be me; I don't represent everyone here or know all the sutff.
scott: With CSSWG moving away from visual styles to implementing functionality, we need to stay on this.
melsumner: Can we ask them to not?
spectranaut_: It would be great is someone in the group could do this. Any takers?
spectranaut_: Is there some way this could be fixed by a process that the CSSWG uses to get accessibility review at multiple stages?
chrisCuellar: I was going to suggest a process, but maybe an earlier review than what they have now?
spectranaut_: There's the wide review before the spec is...
Daniel: Ideally after the spec is first WD to CR, there should be a wide review process across 5 groups. The accessibility review is from APWG.
<Daniel> https://
Daniel: The idea is that someone finds specific issues and can leave comments.
scott: I was aware, and they are in some of the TAG reviews. But I was hoping someone in this group could do that work before it gets to review step.
scott: Early engagement could catch some. There's no interoperable way for mappings to be made outside of Chrome.
scott: Chrome dev team released a blog post of oddly created patterns and now we're just seeing reaction versus having caught it sooner.
melsumner: I have an accessibility review process for products that work, that's like what Scott is describing.
melsumner: My process: when an idea first comes out, the PM must look at the accessibility policy to ensure they are in scope.
melsumner: Then work has to look through the requirements to ensure they mathc.
melsumner: Then two rounds of review before release, with agreements to fix.
melsumner: The CSSWG needs to have acknowledgment that everything they make is accessible.
melsumner: But if someone has the bandwidth to join, great.
<sarah> should we have a deep dive on the carousel stuff?
jamesn: We need something to happen. It seems to go to last minute before accessibility review, and then they write documents on how _not_ to use it.
jamesn: Which people don't read anyway.
jamesn: The only way that seems feasible is to have accessibility people embedded in the WG.
keithamus: I am on CSSWG, but didn't see this come up. I'll endeavor to bring the accessibility point of view to the WG.
jamesn: The AI conclusion is that you have volunteered, keithamus.
spectranaut_: I see sarah asked to do a deep dive on this; can you make an issue?
scott: While it's shipped in one browser, it's fixable because it's not in other browsers.
keithamus: No signals from other browsers for interest.
Matt_King: I like the idea of a deep dive.