W3C

– DRAFT –
ARIA WG

30 October 2025

Attendees

Present
aardrian, Adam_Page, benbeaudry, ChrisCuellar, chrishtr, CurtBellew, Daniel, filippo-zorzi, front-endian-jane, giacomo-petri, Jacques, katez, keithamus, lola, pkra, sarah, scott, Siri, Siri3, Stefan
Regrets
smockle
Chair
-
Scribe
front-endian-jane, jamesn

Meeting minutes

Zakim start meeting

New PR Triage

New Issue Triage

jamesn nothing to discuss on first item (new issue), just a version bump

aardrian I'll take a look but it likely won't be needed because radio groups can be required

New Issue Triage

benbeaudry I am just looking for feedback from jcraig on this one
… there is a difference on how aria-invalid is being applied between Chrome and Safari, and grammar errors marked with this are not being announced by Chrome on MacOS

jcraig I will take a look at this, you can assign it to me

jamesn we can lump 2664 in with 2653, the name "off" doesn't make sense

jcraig We need one mapped to undefined, but "off" doesn't sound like undefined. We need a difference between it being undefined and it only be announced when focus is on the element. This isn't just a wording things, but need to be in the IDL reflection so undefined is the default and we have a new word for timers and other things.

front-endian-jane I can take a look

jamesn is a change needed for 253, or is this a downstream bug with aria-details not being announced

Scott there is a missing note in core-aam to say aria-details should be announced

jamesn It feels like this should be done, and maybe browsers are already doing it?

scott You can assign me but I may need help with parts

<scott> w3c/aria#2668

Scott this is a sub issue so it isn't appearing in the query for new issues to discuss in GitHub. There are wildly different results in screen readers with tooltips. We can discuss this or save it for a larger discussion on tooltips at another point.
… I can create a PR and we can agenda discussing it once there is a PR.

Zakim close item

Zakim next item

WPT Open PRs

jamesn I don't think there is anything to discuss for new WPT PRs

TPAC agenda

jcraig I am running the automation agenda item, I can run the AccName vs Content one if someone else can take that one

jamesn I can prep the AccName vs Content one if you are already doing the automation one

scott I can provide some context to help prep, though I'm unsure if I can attend.

jamesn I suspect that we will cancel next weeks meeting because of TPAC and travel. If anyone has questions about the agenda please reach out.

cyns Is it possible to create separate calendar invites for each meeting?

Daniel I will look into it

jcraig if any of the times don't work for people who are attending remotely let us know
… it would be good to get 4 issues we can discuss and get through, ping myself and Val if you have issues you'd like discussed
… We have a joint meeting with APA to discuss how to deal with spec changes that span both groups and so we can provide accessibility expertise when needed.
… We also have a joint meeting with AGWB to discuss what may be required of us for WCAG3.

Daniel We will find out in the future based on work from them about when/how they'll want to work with us

Expose implicit ARIA semantics (browser-defaults and ElementInternals)

benbeaudry I want to give a simple summary to keep it short: ElementInternals were created to query about the attributes that the author set, but there is no way to get ARIA attributes from this, but testing tools like axe run in the browser and need to check for author made errors. They don't care about the computed tree for this, they need the

author edited values.
… These tools have no way to run these tests and came to us to ask for a fix to this problem.
… We are in the very early stages of this, still brainstorming ideas of how to do this without creating a web driver specific API because that wouldn't git their need. It needs to be secure and protect information about whether a user is using an assistive tech.
… In our first solution we though we could expose the internal value via ElementInternals and it didn't wouldn't work when we validated it, so we wanted to only expose only the ARIA implicit values as a read-only API, or always expose all of the properties that the author changes so future values would get captured.
… They don't want to just open up ElementInternals, but the community creating accessibility testing tools kind of need this for their tools to work.

<Zakim> jcraig, you wanted to say I'm hesitant to introduce an API that breaks encapsulation for testing purposes. Adding something to WebDriver or extensions is fine of course, and what Axe-Core needs is already available as an audit in WebKit, probably others.

jcraig there are so many pieces of the chain that need to be automated, axe is one, web drivers are another, acacia is another. I don't disagree that it would be useful for Deque to know these details for axe-core. Why do they thing it needs to be an open web API versus a web driver? We are working to expand the web driver, though it may not solve

the case for them.
… In Safari we shipped a feature called Audits and reached out to testing venders about this with a prototype a11y audit. There are extra hooks in a secure, developer context. I think Chrome has similar features. Is that enough?

benbeaudry We have discussed that a lot. Their reasoning is ideally yes, that is what they would do, their JS API is used widely in production in non-developer contexts, so if their thing will fall apart. This is the most upvoted issue from users of axe-core because it breaks on custom elements. It is returning false positives on those components.
… they are asking if we can return to the state they had before ElementInternals broke things and it has worked for the past 25 years.

<Zakim> jcraig, you wanted to suggest framework component vendor dev vs client dev

giacomo-petri ElementInternals was created to hide of some of these things, so I don't think this is an ARIA problem

jcraig I see this as two different clients. One of the things that needs to be validated is did the application dev do the right thing, the other is if they are using a framework, is the framework accessible

jcraig the web is more complicated than when axe-core started, and so this break incapsulation

jane: wanted to mention that the line between fw author and content author is blurry
… if they have to invest a large amount of effort to setting up different testing systems w/ custom components vs no
… not just a deque issue - there is lots of money and effort built around the way things work. Just because we switch to custom components it feels to developers that this should be the same.
… want to voice that it is going to be a large cost. Can we do a serious analysis of what are the security concerns. What is the impact of this being exposed and whether or not that is worth it.

benbeaudry axe-core is the basis of a lot of testing tools out there so this would have impacts and break backwards compatibility for a lot more the Deque.
… There is reason to make ElementInternals private, it should be scoped, closed, encapsulated, but it was also the only way to set some ARIA things. The security was inherited by was not the reason why people chose it, it was just the only way to set things for custom elements.

cyns Wilco's point is good that not everyone doing this is in an a11y environment and may not have the permissions to do more complete developer testing

<Zakim> jcraig, you wanted to demo what I'm talking about

jcraig (demoed how audits work in Safari and how the Accessibility audit works)

jane: would there be a problem if those browser audits can't be in CI and then we get disagreeements between different test flows?

benbeaudry This is a cool technology that would be great, but would cause a lot of breakages and work for people using the existing tools

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

Succeeded: s/this/those/

Maybe present: jane

All speakers: jane

Active on IRC: aardrian, benbeaudry, ChrisCuellar, cyns, Daniel, front-endian-jane, giacomo-petri, jamesn, jcraig, lola, pkra, scott, Siri3, smockle