W3C

– DRAFT –
ARIA WG

06 March 2025

Attendees

Present
Adam_Page, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, katez, keithamus, np-at, pkra, Rahim, sarah, siri, StefanS, zakk
Regrets
-
Chair
ValerieYoung
Scribe
Adam_Page

Meeting minutes

New Issue Triage

spectranaut_: a few from pkra that are editorial

pkra: technicalities; we can talk in the editors meeting

spectranaut_: another editorial for aria#2462

pkra: this is for editors

spectranaut_: aria#2461

Rahim: would be valuable to see how mappings are implemented
… and see where they’re actually declared in the source code

spectranaut_: should we schedule a meeting for this?

Rahim: yes, please

spectranaut_: aria#2460
… conflict for common use of <label> radio buttons
… the relevant HTML is the first example
… should we agenda thia?

pkra: seems like a misunderstanding
… please assign to me; I’ll ask for clarification

spectranaut_: okay, and feel free to agenda it

Rahim: Scott raised an issue last year about grouping non-contiguous radio buttons, this seems related

spectranaut_: please link that issue if it’s relevant

New PR Triage

spectranaut_: new PR from PDF-AAM
aria#2466
… we have reviewers assigned already
… should we also agenda this to discuss?

zakk: yes, please
… this is the initial import for each AAM mapping
… this is an export from our Google spreadsheet

spectranaut_: let’s let the reviewers get to it

spectranaut_: aria#2464, from pkra

pkra: mostly for editors
… our CI isn’t working as expected
… this is also a warning to anyone with an open PR
… I’ll finish this and update all the open PRs
… but the older ones will be difficult because of merge conflicts
… let’s merge this one, and then I’ll rebase others

<scott> fyi - james craig is running late today, and may not be able to attend. i'm also not really here. bye

pkra: a couple minor changes to other specs because prettier is running on them, so we need to talk about it on the editors side

spectranaut_: I’ll review this

WPT Open PRs

spectranaut_: wpt#51107

Rahim: at the beginning of the year, the Interop gropu had to roll back some tests
… to prevent them from being counted in 2024
… so this is just reverting those back in
… this specific one has to do with the multiple aria-labelledby spellings
… so I’ll review

spectranaut_: and then we can merge

Deep Dive planning

spectranaut_: SVG is scheduled for week after this
… I’ll make an event for that
… also, heads-up that an accname whitepsace deep dive we had scheduled for Dec will be rescheduled for either March or early April
… keep an eye out

giacomo-petri: the cards deep dive can be removed from this list

pkra: can we close the issue?

giacomo-petri: yes, I think so

spectranaut_: I’ll close it (aria#2162)

spectranaut_: would you like to talk about any of these others?

giacomo-petri: html-aam#562 is about browser heuristics with tables
… but not ready to discuss yet

Daylight Savings starts 9 March in the U.S. For Europeans, that means meetings will be an hour earlier until the 30th.

😭

<giacomo-petri> better for EU people

<giacomo-petri> :D

spectranaut_: meetings will be an hour earlier until the 30th

Resolution to move DPUB to PR now that w3c/aria#2459 has been merged?

spectranaut_: a few weeks ago we discussed this issue from giacomo-petri
… there’s a normative change, so not fully editorial

Daniel: yes, a name from author change
… I’ll argue for editorial, but chances are we’ll need to go back to a candidate review snapshot
… giacomo-petri also raised some other issues

giacomo-petri: the other ones should be editorial
… but I think I found a separate mistake related to doc page break
… the examples disagree with the actual requirement

Daniel: okay, we should wait on this

spectranaut_: for the minutes, does everyone agree that this is editorial?
… or should we resolve these outstanding issues first?

pkra: is this in the spec, or something that ARIA JS is causing?
… the other issues, I mean, like page breaks
… in the spec itself, or maybe a problem with ARIA JS, JSON, child stuff that populates some of the inherited properties from the main spec

Daniel: not sure, will need to check

pkra: if the latter, then the problem is with the automation, and we’ll need to fix that rather than the spec

spectranaut_: Daniel, is there a chance we could still move to PR if the WG agrees that the changes are editorial?

Daniel: just this PR that just landed?

spectranaut_: yes

<spectranaut_> this PR: w3c/aria#2459

Daniel: we have a high risk that if we send this to PR that it will be rejected for not being editorial

spectranaut_: do people agree to try for PR?

<pkra> +1

<hdv> 0

spectranaut_: any objections?

Daniel: if it gets rejected, then it will be delayed by another ~6 months

pkra: I did just confirm that the valuenow issue giacomo-petri discovered *is* an automation issue; not a spec issue

spectranaut_: no objections, so please do go ahead with proposal to move to PR

RESOLUTION: Move DPUB to PR as the group considers adding the superclass role as an editorial change

Cancel next weeks meeting due to CSUN?

spectranaut_: we don’t need to cancel
… since many of us won’t be attending CSUN

ARIA IDL updates: convert eligible attributes to enumerated, new ARIA IDL guidance and examples

spectranaut_: Rahim, you brought this PR back

Rahim: this was a draft PR, and now it’s ready for review

Aligning HTML spec with ARIA's style of DOMString? reflection

Rahim: at TPAC, we discussed ways of improving IDL
… for ARIA attribute reflection
… what motivated this work is that attributes have 2 aspects:
… the content attribute
… and the IDL attribute, formerly known as the DOM property
… those are accessors on JS objects
… correlating to DOM nodes
… every node gets a JS wrapper
… IDL comes into play when we want the JS representation to synchronize with the underlying C++ implementations
… always synced, always aligned
… we call that “reflection”
… aria-expanded ~= foo.ariaExpanded
… ensures the API types make sense for that they are
… boolean attributes are true/false
… nullable strings, non-nullable strings, etc.
… there should be no difference between reflected attributes
… this specific PR has to do with nullable DOM string
… as part of the getter, when the browser gets the value, it no longer checks to make sure the attribute is enumerated
… previously there was a check
… this issue loosened that getter
… so we have plenty of attributes that aren’t enumerated
… that we want to reflect as nullable DOM strings
… so that we can determine the absence of the string
… tl;dr we now have the ability to align with the HTML spec

spectranaut_: this is really great
… been an outstanding issue for a while
… is this issue closeable when we land the PR?

Rahim: the PR has landed on the HTML side
… and approved by HTML editors
… no implementation work is required
… really just a spec bug that was fixed
… we can close the ARIA issue now
… this was the easy one

ARIA IDL updates: convert eligible attributes to enumerated, new ARIA IDL guidance and examples

Rahim: going back to this PR
… after that TPAC discussion
… we talked about improving IDL
… there was consensus that the ARIA WG should really start treating more attributes as enumerated
… enumerated attrs have a very specific definition in the HTML spec
… treated in a distinct way
… for example, the `type` attribute for <input>
… there are a finite number of states
… when missing or invalid, it defaults to `type=text`
… this aligns well many ARIA attributes
… so this PR re-defines many attributes as enumerated
… the same way HTML attributes are treated
… you can review them all in the PR
… I also updated values table
… specified missing values
… clarified undefined
… and also allows us to update our values schema
… now we can have enumerated values that will really capture how things are handled on the HTML side

sarah: I saw aria-valuemin and arai-valuemax and aria-valuenow are all in there
… is that intentional?
… those stood out to me as ones that should accept any numerical value

Rahim: I think you’re right, those should be reflected as numeric values
… but there’s no role-specific reflection for those
… no, those won’t be enumerated

spectranaut_: let’s get some more reviewers, it’s a big change
… and normative

Rahim: jcraig should definitely be a reviewer
… I’d like keithamus’ review as well

keithamus: sure thing

Rahim: this will need some implementor changes
… on the Webkit side, we can remove some custom code and just use the IDL engine
… there’s custom logic we can remove/simplify

keithamus: very likely that the other browsers will have a similar situation
… custom C++ that can be removed

Rahim: on the Chromium side, reflect is not part of the HTML spec
… it’s an “extended” attribute, so technically not part of spec
… but on the Chromium side there’s reflectInvalid and reflectMissing, which is novel

spectranaut_: do we need more browser people to take a look at this?

Rahim: maybe doesn’t need implementor eyes on it yet, just that the ARIA WG is satisfied with the PR

Rahim: on the HTML side, there’s an IDL block for every interface
… wasn’t sure if we wanted to do that in ARIA

spectranaut_: let’s do these reviews offline
… I’ll also review

Aligning HTML spec with ARIA's style of DOMString? reflection

Does aria-atomic have real-world use cases?

Aaron: when ARIA was first being conceived
… how are we going to deal with content changing on the screen
… and we invented live regions
… and then “what if one node changes in a region?”
… we didn’t know the answer
… so we created aria-atomic
… so that people can control it
… but when I see it in markup, it’s usually the author didn’t know what it was for
… and recently TalkBack started to improve web support
… and they asked “is aria-atomic important?”
… if use cases are only theoretical, then I’ll tell them to de-prioritize it

sarah: I have had cases where I wanted to use it in the past but didn’t because of the lack of support
… not worth doing with partial support
… inconsistency is worse than nothing at all
… usually when there are surgical DOM changes like that, I’ve just found that custom visually hidden live regions is a better use case
… and will be handled even better by ariaNotify

<hdv> +1 to Sarah's point

hdv: I’ve also been thinking about use cases
… and came up empty for this

Aaron: can we keep it in the spec but deprecate it?
… add a note that it’s not consistently supported now

sarah: we might want to poll people who work on smaller things with less infrastructure than the big enterprise applications I work on

Aaron: let’s say you have a word processor with a status bar showing the row and column your cursor is on
… I think the idea was that you could have a label in front of it
… you could put aria-atomic around the value that the label is pointing to

sarah: yeah, that’s similar to things I’ve encountered in the past

<hdv> +1 to deprecate aria-atomic

spectranaut_: is anyone against deprecating
… no

RESOLUTION: deprecate `aria-atomic` in the spec

Summary of resolutions

  1. Move DPUB to PR as the group considers adding the superclass role as an editorial change
  2. deprecate `aria-atomic` in the spec
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/RESOLUTION M/RESOLUTION: M/

Succeeded: s/... RESOLUTION: deprecate/RESOLUTION: deprecate `aria-atomic` in the spec

Maybe present: Aaron, spectranaut_

All speakers: Aaron, Daniel, giacomo-petri, hdv, keithamus, pkra, Rahim, sarah, spectranaut_, zakk

Active on IRC: Adam_Page, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, katez, np-at, pkra, Rahim, sarah, scott, siri, spectranaut_, StefanS, zakk