W3C

– DRAFT –
ARIA WG

13 August 2026

Attendees

Present
cyns, filippo-zorzi, giacomo-petri, HaTheo, Jacques, jamesn, jcraig, JohnJansen, keithamus, lola, Matt_King
Regrets
-
Chair
spectranaut_
Scribe
lola, HaTheo

Meeting minutes

New PR Triage

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

<spectranaut_> w3c/aria#2865

jamesn: I've reviewed. Added peter and Valerie, this doesn't need anymore

jamesn: errors aren't in spec, in comments and other places that aren't as important.

jamesn: the only one i noticed for you is a misspelling of one of the roles for core-aam, it's a computed role so i want to make sure nothing is using it

<spectranaut_> lola: this is from issue 608 in html-aam adding a new row to the spec for link with a click handler on it, in alignment with major browsers: w3c/aria#2863

hatheo: i can review

siri: me too

spectranaut_: we should have an editor of html-aam too

New Issue Triage

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

spectranaut_: we have issue from CSS working group to discuss overview:clip, should we agenda it?

johnjansen: we discussed this last week and people were confused by how this work.

jcraig: this affects more than just voiceover users, screen reader users can skip over the long text. yes it should remain exposed, it's not an error

spectranaut_: I think this is something we should rediscussed

Matt_King: we should discuss and go through demo

spectranaut_: we can discuss next week

johnjansen: james if you have any test, that'd be great

jcraig: we haven't had anything to test yet

jamesn: real world usecases would be good. Abstract example doesn't properly show the issue.

johnjansen: HuffPost is a good example, any long example

jcraig: can you add that example to the issue to please?

johnjansen: yup

WPT Open PRs

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

spectranaut_: rego is looking at test type fixtures. I'll look at this

Deep Dive planning

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

Define proper AT exposure for aria-colindex when web authors specify this value on a row

spectranaut_: this is a request from a firefox developer. If aria-col-index should the browser also expose the value on all cells in the row?

Matt_King: that's difficult to understand. how can you have 5 colomns with the same col-index?

jamesn: I think this may be a copy paste error. it should be row-index right?

jcraig: it might also be talking about first column header which would then cascade down to each row?

Matt_King: is the row-index already not supported?

spectranaut_: maybe this is a typo?

jamesn: what does it say in the spec?

Matt_King: we actually have an APG example for this

jamesn: explains specification

spectranaut_: They want to just know if aria-col should be indicated. and I think it does

jamesn: I think it does

spectranaut_: any agreement from the group?

Keith: anyone try to just open the example?

spectranaut_: I don't see aria-colindex communicated in computed properties, sounds like this would be a bug on browsers.

spectranaut_: sound like there is agreement that it needs to be communicated, right?

Matt_King: yes, this is one of these situations where if you expose invalid options it would cause problem.

group agrees

Matt_King: proposes that we should consider the author fails to provide values then he user agent must not expose it.

jamesn: I would be wary of exposing the author must not do something here.

jamesn: did we say this was in aria, should it not be in core-aim?

spectranaut_: my understanding is that aria exposes where implicit items are communicated. e.g. in the case of a default value.

jamesn: my understanding is platform inconsistencies that should be mapped in core-aam.

spectranaut_: we should/might have to write a core-aam test to test this.

jamesn: this seems very similar to we expose things like number of list item calculations, we should think carefully about how we expose this.

<jamesn> https://w3c.github.io/aria/core-aam/#mapping_additional_position

jamesn: it seems very similar to this

spectranaut_: I am ready to move on, but we don't have concrete next steps.

jamesn: we have a decision which is good progress.

spectranaut_: added help wanted

interactive elements contained in button?

spectranaut_: we talked about this last week, and James Craig, had a open question.

jamesn: this shows up as an issue mostly when you are using voice over with chrome.

jcraig: I am familiar with that particular concern. we could consider this but that would be likely shipped as an experimental feature.

Matt_King: can you clarify what this is?

jcraig: Buttons have always not exposed children, but we found this changed in chrome and we are wondering if this could cause web compatibility fallout.

Matt_King: just to clarify so we are exploring if buttons can have children in the A11y Tree.

jcraig: yes, that is the exploration.

Matt_King: I've noticed that this(children of button) happens quite frequently in invoice payment, and you have to use NVDA Advanced Navigation.

jcraig: have you tested this and found it performs better in safari?

Matt_King: no, I have only looked at this in Windows and found that this requires the usage of Advanced features within NVDA. And with the information exposed in this way there are a very small usage of people who can do that.

jcraig: can you clarify the case? I am not sure it is the same.

jcraig: that seems like it is the case actually, can you share a URL?

Matt_King: one was for a landscaping invoice/payment.

jcraig: do you remember enough to conjure up a test case here?

Matt_King: yes, it's also worth noting we noticed a recovery technique where browsers were taking the child elements and making them siblings.

spectranaut_: it sounds like James you are willing to take this on and explore can I assign this to you?

spectranaut_: this would just be about thinking about how VoiceOver handles buttons with things inside of it.

Matt_King: did we catch from last week the cases where the browser expose children as siblings as a recovery technique. if we could do that it seems like it would be very powerful.

<spectranaut_> ack keithamus

Jacques: I think it's worth exploring, but I would like to make sure we make sure the Accessibility tree matches the structure of HTML

Keith: I would second what Jacques said, I think there is a lot of potential for synchronization issues and other bugs.

<Jacques> Clarification for the minutes: I am not against exploring, I think the effort might be worth it, just want to take cation.

Matt_King: I was considering this strictly as a recovery mechanism, and would imagine it should still show issues in the console.

Matt_King: I like to read the console

giacomo-petri: can I ask something to James?
… I am pretty sure a while ago I tried this.

<HaTheo> s/I am not worth exploring/I think it's worth exploring/

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

Diagnostics

Succeeded 4 times: s/mattking/matt_king/g

Succeeded 4 times: s/matt_king/Matt_King/g

Succeeded: s/aria-rcolindex/aria-colindex

Succeeded: s/I am not worth exploring/I think it's worth exploring

Failed: s/I am not worth exploring/I think it's worth exploring/

Maybe present: Keith, siri, spectranaut_

All speakers: giacomo-petri, hatheo, Jacques, jamesn, jcraig, johnjansen, Keith, Matt_King, siri, spectranaut_

Active on IRC: cyns, filippo-zorzi, giacomo-petri, HaTheo, Jacques, jamesn, jcraig, JohnJansen, keithamus, lola, Matt_King, spectranaut_