W3C

– DRAFT –
ARIA WG

06 February 2025

Attendees

Present
Adam_Page, filippo-zorzi, giacomo-petri, jcraig, katez, pkra, Rahim, scott, smockle, StefanS, Summer
Regrets
BryanGaraventa, CurtBellew
Chair
ValerieYoung
Scribe
Rahim

Meeting minutes

New Issue Triage

spectranaut_: For core-aam #245, Joanie asked that it be updated. Aaron pushed back on whether screen readers will be made aware of the change. I will assign this to myself

jamesn: For aria #2424, we could explicit put (parent/child relationships). It may already be under aria-busy
… in the spec, but may not be a normative mention

jcraig: I can find it

scott: The way that `aria-busy` has been communicated through automated testing results, led people to believe they can use it [in any way]. Could be clarification that testing tools could be clear on what the expectations for `aria-busy` are

spectranaut_: Is there more to discuss here, and where language might be different?

jcraig: It's already assigned to me

spectranaut_: Regarding aria #2423: Giacomo is pointing out that an intervening element/container with `<div aria-live>` should be allowed
… I'm interested in looking at this as I helped with this language

jamesn: Let's agenda this, more discussion is needed

jcraig: For aria #2422, came out of a bug that Amazon recently fixed (presence of `aria-modal` caused some browser/AT combinations to not move focus to it). Causes some AT to get locked. There are already heuristics that exist in spec. e.,g `aria-hidden` on `<body>` is ignored
… I'm curious if there are ways to list these in the spec; also, perhaps call them out (e.g., via ReSpec) and maybe aggregate them somewhere in the spec

New PR Triage

spectranaut_: On aria PR #2425, Peter wanted to review this? (not on the call today)

jcraig: I can take a look

spectranaut_: Any objections to aria PR #2421? (Merged.)

jamesn: I will take a look at aria PR #2420

WPT Open PRs

jcraig: Would be great to have reviewers for WPT PR #50507. It was previously approved and there was one change that I made where I commented what the change was; only the last test changed to DFS (depth first search)

scott: I want to be added to this as well

jcraig: Hopefully this will unblock some engines, and then the (nameFrom: heading) PR can be merged

Deep Dive planning

spectranaut_: No deepdives planned

spectranaut_: If you have any objections, you can object now (via email). Just making sure that everyone is aware

jamesn: Did everyone see the CFC? I sent it to the mailing list

jamesn: ...there haven't been any positive/negative responses (which is fine)

spectranaut_: For newer folks, CFC is a "call for consensus" and how we formally make decisions. Most of the time, consensus is tracked in Github

jamesn: Transition documents (like taking control of documents). It says that "silence is consent" for the decision but if you don't object, but if you feel the need to reply feel free

RFC to move DPUB-ARIA and DPUB-AAM to proposed recommendation

Update text node definition

Rahim: Is this OK to merge?

Rahim: See related PR about updating ARIA readme for ReSpec aliasing

Add normative text on calculating aria-level, aria-posinset, and aria-setsize

pkra: I wanted to check the status of this (can't recall why I agenda'd this). It was an old PR and was going through the ones I was assigned to review, and I left comments

spectranaut_: It looks like it needs browser implementations (or to confirm browser implementations)?

pkra: We can skip it due to Sarah's absence

jcraig: If I recall, it shouldn't be changed until there is a way to test the change (`aria-level` is not testable)
… only role/label are testable currently (with WPT)
… it's a broad enough scope change without testability (to fix a problem due to inability to test) would be a bad step forward [Update: retracted later in the call; I was referring to another issue related to level, setsize, and posinset.]

Matt: Is it possible to add a comment to this PR, something that would help us to know when to bring this back up? Is there some way that we can not lose track of it

pkra: I put on the agenda for editors

Matt: Is there a timeline for when we'll have more testable attributes?

spectranaut_: No timeline but discussed in a11y interop group

jcraig: Jamie Teh has made progress on more robust testing in Gecko

pkra: This isn't technically a big change, it says that user agents MUST do this

jcraig: You're right, the spec says this; my concern is verbosity

Matt: The spec is inconsistent; it requires it for certain roles like `article` but not other roles and in other cases, there is no normative language

jcraig: Because `aria-level` is used for `heading`, there isn't a way to do role-specific mapping in a way that this spec change requires
… I'll comment in the issue or we can discuss further now

spectranaut_: If you want to continue discussing this, that's a different issue than this PR? (Peter K. confirms)

jcraig: Isn't this adding normative text for computing `aria-level`? This attribute has overlap with headings so can't reliably map IDL (due to role-specific determination)
… when `aria-level` is not defined (e.g., `<div role="heading">`) for example; the issue is that the problem is ATs didn't assume author intent. Jumping to `aria-level="2"` might not be what author intended. The current VoiceOver behavior is less verbose and doesn't misrepresent something the author didn't intend

jamesn: I'm certain that heading level "2" was determined if it wasn't specified (and moved to the "Fallback" section in ARIA section). See ARIA 1.1

jcraig: Thanks for pointing out it was in ARIA 1.1. I still have a concern

pkra: This is one of the reasons I responded (to James C.'s comment), and added a note in the PR to comment on how other screen readers (e.g., JAWS, NVDA, ORCA) and how they behave
… this discussion wasn't supposed to touch on headings
… if it's not in the PR, we should discuss that

jcraig: I wanted to ask Rahim if there was a way to do this in IDL (specify heading level when the attribute is absent)?

Rahim: not that I'm aware of due to the current IDL attribute type for `aria-level` being `nullable DOMString?`. Would require a change in the IDL type (or introducing a new attribute ala `classList`/`className`)

Ambiguous but normative requirement about hidden nodes is hidden by default in AccName

Rahim: Can this issue be closed?

spectranaut_: Feel free to close it

[AriaNotify] Scope proposal for V1 of API

spectranaut_: People can take a look if they're interested, will be discussed in a future meeting

Minutes manually created (not a transcript), formatted by scribe.perl version 242 (Fri Dec 20 18:32:17 2024 UTC).

Diagnostics

Succeeded: s/it's a broad enough scope change without testability (to fix a problem due to inability to test) would be a bad step forward/it's a broad enough scope change without testability (to fix a problem due to inability to test) would be a bad step forward [Update: retracted later in the call; was referring to another tangentially related issue.]/

Succeeded: s/was referring to another tangentially related issue/I was referring to another issue related to level, setsize, and posinset/

Maybe present: jamesn, Matt, spectranaut_

All speakers: jamesn, jcraig, Matt, pkra, Rahim, scott, spectranaut_

Active on IRC: Adam_Page, filippo-zorzi, giacomo-petri, jamesn, jcraig, katez, pkra, Rahim, scott, smockle, spectranaut_, StefanS, Summer