W3C

– DRAFT –
ARIA WG

04 December 2025

Attendees

Present
Adam_Page, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, Jacques, katez, pkra, sarah, scott
Regrets
-
Chair
jamesn
Scribe
Adam_Page

Meeting minutes

<jamesn> adendabot, find agenda

New Issue Triage

jamesn: new issues
aria#2691
… synthetic triggering of aria-actions
… need agenda for next week
aria#2689
… aria-placeholder with combobox role
… agree with scott’s response
… any more discussion, or PR?

scott: PR

jamesn: who’d like to take assignment?
… will see if Mario would like to take it
… and tag it `good first issue`

Daniel: we have something like this in our product
… neither JAWS nor NVDA can read
… looked into ARIA spec and found that placeholder’s not supported on combobox role
… we think it should be
… for editable comboboxes
… wanted to bring to the group for opinions

spectranaut_: you tried it, and SRs don’t support?

Daniel: yes, and that agrees with the spec

Bryan: I’d support adding that

jamesn: sounds like something we could do a PR, but would need to check with AT for support — but if browsers exposed it, maybe it’d come for free
… but a good first step would be a PR

spectranaut_: agree

Bryan: it does work on an input element with a combobox role
… placeholder does; not sure about aria-placeholder

Daniel: our tests show it doesn’t work
… Mario can do the PR

jamesn: not urgent
… PR’s a good start, then we can discuss
aria#2686
… should this be agenda’d?

cyns: there’s another similar issue

jamesn: isn’t the other one more about whether these can be read by testing tools
… this is not quite the same

giacomo-petri: we are differentiating implicit vs explicit now
… not really clear if a role set by elementInternals is implicit or explicit

jamesn: my opinion is that it’s explicit
… but should have more discussion about implications

scott: I agree
… a custom element doesn’t have an implicit role

giacomo-petri: okay
… we also need to define if we set role by attribute which one takes precedence

jamesn: this isn’t specific to roles though, right?

giacomo-petri: correct

jamesn: it’s a broader elementInternals issue, should be defined in that spec
… not an ARIA question

giacomo-petri: yes, that’s true

scott: last I recall, ARIA is supposed to take precedence
… for overrides
… but is that documented anywhere? not sure
… needs to be tracked down

jamesn: is that true for any attribute?

scott: not sure

sarah: my general understanding is that all attributes could override elementInternals, but not certain

jamesn: can anyone sign up to investigate this?

scott: I will reach out and do some spec spelunking

jamesn: thanks, I’ve assigned you
aria#2685

<LucasRadaelli> question to other screen reader users: joined the meeting via zoom web, and NVDA seems to be blocked on a dialog and I can't interact with the screen (to turn on mic for example), has anyone ever seen this?

spectranaut_: I think yes to this issue’s question
… giacomo-petri, would you like to make a spec change?

jamesn: would that be a new section?
… or just put in prose for the few things that require it?

giacomo-petri: I think a section and then a row for each role

spectranaut_: I think that’s largely editorial

jamesn: are there any others that need this?

giacomo-petri: maybe

jamesn: a tree probably requires a treeitem for example

giacomo-petri: I’ll take assignment

jamesn: ... aria#2683

pkra: no need to discuss

jamesn: ... aria#2679
… no need to talk about
aria#2676
… from jcraig

jcraig: think we should keep listed attributes since they’re deprecated

pkra: I’ll take this editorial task

jamesn: aria#2674

jcraig: I have a PR for this one

jamesn: aria#2672
… should role=
… "menu" be an allowed child of menubar?
… I think yes

scott: some of the effort in open UI to specify menubar element was trying to work around this apparent oversight
… I’ll start a PR

jamesn: aria#594
… aria-current and scrolling
… came up in WG
… would this be for CSS-AAM?

spectranaut_: I think yes

jamesn: I’ll move it there
aria#2671

pkra: talked about it at editor’s meeting

jamesn: aria#2669
… we already talked about this?
… yes, assigned it already

New PR Triage

jamesn: new PRs
aria#2690
… from scott

scott: when I did the work on this back in 2500, I asked reviewers if the new requirements should be repeated
… so got back to this and made this PR

jamesn: I’ll review, and any other reviewers?

Bryan: I’ll review

Adam_Page: I’ll review

jamesn: aria#2688

Daniel: I’ll take care of these PDF ones

jamesn: aria#2682
… Android mappings!

spectranaut_: I’ll review all of them

jamesn: any other good reviewers?

cyns: I will

<LucasRadaelli> I also would like to review

<LucasRadaelli> I can't turn on my mic, sorry

<LucasRadaelli> lucasradaelli@gmail.com

<LucasRadaelli> or just lucasradaelli

<LucasRadaelli> I think val added me?

<LucasRadaelli> I can't speak, sorry -- can't interact with the zoom window for some reason!

jamesn: have also added LucasRadaelli as a reviewer
… I’ll add the same reviewers for all the Android PRs

jamesn: aria#2677

jcraig: thanks to scott for reviewing
… marquees and timers were specifically the main use case for aria-live="off"
… you’d get announcements, but only when you land focus on the elements
… so there were some implementation differences
… but due to progress of browsers currently, none of them support any announcements for aria-live="off"
… and it’s wise that they don’t
… because there’d be a weird distinction
… so currently we have alignment
… everything but Orca
… basically the fix for this is that marquee and timer should just not be listed as live regions
… because aria-live="off" is their default value, which means they do nothing; effectively *not* live regions
… this is a case where we found alignment and should fix the spec instead

jamesn: so there is absolutely no difference in behavior?
… so aria-live="off" doesn’t do something special when the thing has focus?

jcraig: we tested multiple WIndows screen readers and VO, Firefox, Chrome, Edge
… Webkit on Mac, etc., and found that no SR or browser combo supported any announcements
… whether for marquee, timer, or aria-live="off" on any element
… that said I think we should keep the role

scott: when I did the review of this, I also did some testing and got similar results
… I do recall this working in the distant past

jcraig: me too
… but now, nobody does it

jamesn: could it actually be useful though?
… or has the market decided it’s not important?

jcraig: the latter, and also it’s confusing, and ariaNotify is coming

Daniel: I think someone put an example of a timer in the issue
… SR didn’t, but braille did

jcraig: interesting
… please comment to say the tech stack for that, Daniel

jamesn: we have a CSS-AAM stub, no need to review
aria#2670

scott: made the issue prior to TPAC
… and now made this PR to follow up
… reviews welcome
… if you think that tooltip should not be named

jamesn: I’ll review

Adam_Page: me too

sarah: me three

jamesn: does anyone like tooltips?
… <crickets>
… 3 reviewers, perfect

WPT Open PRs

jamesn: jcraig, anything we need to look at?

jcraig: #56417 — haven’t reviewed this one yet
… just a yaml change, shouldn’t be relevant to this group
… haven’t seen an update since Oct 30
… #55784 I have reviewed
… and if anyone’s interested, please check this out
… additional reviews welcome
… actually, @LucasRadaelli, would love to have your perspective

<LucasRadaelli> do I need to do anything to be added?

jcraig: I’ll get him added to the WPT project

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

Diagnostics

Maybe present: Bryan, cyns, jamesn, jcraig, spectranaut_

All speakers: Adam_Page, Bryan, cyns, Daniel, giacomo-petri, jamesn, jcraig, pkra, sarah, scott, spectranaut_

Active on IRC: Adam_Page, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, Jacques, jamesn, katez, LucasRadaelli, pkra, sarah, scott, spectranaut_