Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
keithamus: New HTML menu elements are still in discussion, not landing anytime soon
<spectranaut_> w3c/
spectranaut_: I think people are aware that we're working on getting computed a11y properties, similar to get computed label/role (i.e., new WebDriver command)
… this new PR (ARIA #2800) adds more about get computed properties. Trying to work out a set of proposed attributes to be surfaced, for which attributes get mapped to computed a11y properties; including others such as focusable that are HTML attributes
… there are people who should be reviewing it but if you're interested, it would help for ensuring clarity
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<HaTheo> I started to read it happy to add myseld
Matt: I was supposed to add people to ARIA #2791 (add a list of invitees) for that deepdive, I'll take care of that
spectranaut_: RE: ARIA #2748 another thing is gathering ideas for browser dev tools. Reminds me that the Web Engine Hackfest is soon, we talked about potentially having a session there. There are other browser engineers so we could find time in the morning to talk about this topic and people could join remotely
Cynthia: I'll be there, Lola would like to participate as well
keithamus: I'll be there
spectranaut_: I'll propose a session, will email this group with a time in case anyone wants to attend remotely
TPAC - Oct 26-30 2026, Dublin Ireland
spectranaut_: Just a reminder for TPAC
Daniel: Happening 26th of October thru 30th; this time of year we're discussing whether we should have Mon/Tues as individual group meetings. For now, it would be nice to start thinking about potential TPAC things to discuss but first, log intention to meet (which I assume we want) before June 17
spectranaut_: we (ARIA WG) are interested in meeting, hope as many folks as possible can come
Cynthia: Will there be invited expert scholarships this year?
Daniel:
… still being decided, will let you know
WPT Update - new AAM tests
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<spectranaut_> https://
spectranaut_: New AAM tests landed a month ago (exciting!). There is an AAM test directory in core-aam, automated tests for roles/attributes. Can write tests for IA2, Linux and Mac
… big change from what we've had before
<spectranaut_> https://
spectranaut_: I will finish writing tests for Linux for all of core-aam roles/attributes, and would like to start working on events test infrastructure (this is just for static mappings)
… the other thing I wanted to ask, it would be nice to have regular reviewers of tests and changes to infrastructure. All in Python, pretty straightforward
<HaTheo> +1 I would love to know these
spectranaut_: if you're interested in getting to know these (core-aam) tests, let me know
keithamus: is there a reviewers group?
spectranaut_: I don't know, I think they have that in WPT (you can assign directories to people)
keithamus: I'm definitely interested
spectranaut_: Maybe I can have a one-off session (probably after Web Engine Hackfest)
Open WPT PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<spectranaut_> accessibility properties: web-platform-tests/
spectranaut_: WPT #59685 from Jamie Teh is related to get a11y properties work
giacomo-petri: I think there's an interesting one related to core-aam; changed mapping for images with whitespace only value (only checked accname and not role and there's inconsistency in browsers). Browsers should be consistent in treating whitespace only values rather than being ignored for images
scott: it's WPT #52480, img src/srcset has landed in HTML but not WPT
spectranaut_: is there a topic for the ARIA WG to discuss?
giacomo-petri: maybe we can add it to the agenda for the next time; the specification for whitespace alt attribute treatment is approved so just around aligning how browsers behave
jcraig: it should be fine, we've got 2 reviews already
spectranaut_: we can discuss this, and open bugs on browsers. Or should this be discussed first within the ARIA WG (spec change already agreed upon), next step is open bugs on browsers
jcraig: didn't see anything in this list that would be unexpected for a role; maybe there's a scenario of img within picture is exposing the role of the parent (can't remember it)
… point of tentative tests is to take out remaining discrepancies for implementations
giacomo-petri: I think my comment is not being merged
jcraig
jcraig: it's merged, but I can revert it now
giacomo-petri: I've replicated all of the test cases with alt = whitespace
jcraig: I'll create a new issue in the interop accessibility repo, that way it's here
jcraig: please do the additional work in that new interop a11y issue
Rahim: should the html-aam issue remain open?
spectranaut_: yes, the WPT is not merged yet
aria-actions: handling focus when actions are synthetically triggered
Jacques: I've pinged Sarah to see if she can join
Matt_King: I can talk about the PR I made, better to get Sarah if she can join
Headings should not be labeled by the author
spectranaut_: discussed briefly in triage, would be nice before being closed as duplicate there was consensus from the group
… two issues that can be marked duplicate of each other. This is an issue we should tackle soon, i.e., review roles and clarify expectations from author, and the therapist is whether label (author-provided) should override content
spectranaut_: any proposals for making headway, and are people in agreement that we can close this out as a duplicate (to address JAWStest's concern)
… Peter thinks we shouldn't make this breaking change to ARIA without considering other scenarios of names for heading
Matt_King: I haven't gone through each of these issues, but is anyone aware if we have a list of scenarios where people think it is legitimately/useful to have an author name a heading? Any examples in the wild?
… and everyone agrees it's useful and allowed?
scott: I brought this up before; I called out in another issue that there things like headings and list items that do allow name from author but in reality, they behave rather poorly. Been a year or so since that issue was opened, and my testing during that time was pretty sporadic. Name from author was not consistently respected, especially for Windows screen readers
… came across an example where somebody gave an accessible name via aria-label to a heading, but they put other things within the heading element. This is a signal that one may be trying to get rid of content inside of it (i.e., the heading). No defined concept when text is rewritten within text, e.g., ARIA doesn't allow similar scenario for paragraph elements
jcraig: My goal is to argue for permissiveness over restrictiveness. The spec maintainers/authors know that web developers make mistakes, or have a variety of experience/skill/judgement. The scenario where they shouldn't do something but did, is one where there are a lot of examples. I. think we shouldn't change the spec based on an AT bug
… if there's an implementation problem (e.g., can't be implemented on a platform a11y API), absolutely we should change it. But if there's a usability issue that's not a bug, we should allow for permissiveness using priority of constituencies and prioritize users of AT over web authors
… the thing the (AT) user needs still is in the DOM or (a11y) tree; we might know what they (devs) did wrong, but we can anticipate it
… maybe there's something from main navigation where only the emoji is visible but only the aria-label is the text alternative. I think we should think of examples where we have allowed this
Matt_King: I really agree with the notion that we go with the priority of constituencies. However, what we're running into is how we prioritize those constituencies that gives the best results for everyone
… there's even ways we can prioritize authors better if we don't have this permissiveness, there's certainly ways to do that: to nudge authors to give users a better experience. One of the reasons we now prohibit name from author for paragraph is thinking about the needs of users
… part of the reason is also simplicity of the spec. If we're more or less permissive across the board, might be confusing for authors (one case it overrides, another case it augments) so we end up in situations where authors don't know for sure what's going to happen
… the way VoiceOver supports makes it harder (wish VoiceOver would ignore the label). There's a lot of different kinds of tradeoffs and we should be thinking about them carefully, and think how we've treated other similar situations
jcraig: I agree with all of what you've said
scott: I personally don't think this makes much sense (to allow names on headings) given the inconsistency of how things behave. Raised similar issues in the past. I'm not against permissiveness so long as there is clarity in why there is inconsistencies and what the behavior should be. Right now there is inconsistency for other similar roles
… we (ARIA WG) need to do a better job of explaining experience and how the context should be exposed
… and explain why we don't allow it for paragraph elements but allowed in others. There should be consistency and clarity
<Zakim> jcraig, you wanted to hypothesize an example of why this might be listed on li or heading vs para
jcraig: to help with clarity: have seen some scenarios where for example a list item, semantics depend on the user's need. Do we want to read the whole thing and let author decide what that is, or let user decide how to consume the content
… let's say there some text in the heading, and image + couple buttons (HTML is permissiveness in that regard, not just ARIA). Do we want the name from author disallowed so either concatenate child elements, or do what VoiceOver does which is announce summary of descendant elements to let user dig into the content (and not tediously listing everyone without letting users skip past it)
… we have to make the best choice for what the author intended, and what the user's primary use case is in this scenario and try to support the other one in each of those cases. No right or wrong answer in these scenarios, but open to suggestion from AT/browser devs
Matt_King: I have some other thoughts in taking a principled approach to get consistency but to do this, we need one issue and figure out exactly where we want to have this conversation
aria-actions: handling focus when actions are synthetically triggered
<spectranaut_> discussing Matt's PR: w3c/
Matt_King: Used this PR to push this discussion of priority of the user agent using the names specified by the author (was a SHOULD, not sure why this wouldn't be a MUST). The issue most related to ARIA #2691 is some text I proposed there related to the user agent not doing default focus transfer in response to a click event
jcraig: I wanted to ask Matt to clarify example; could you summarize what happened before and what happens now (the PR) at a high level
Matt_King: are you asking about the APG example?
… there's a brand new PR in ARIA (ARIA PR #2806) - "Add browser requirements that support synthetic activation by AT"
Sarah: I'm most interested in the last item to do with default focus; this part of ARIA doesn't touch that realm of things. I'm most interested is whether that should be in ARIA or somewhere else worked out between browser/AT
… e.g., on mobile web for Apple platforms, pressing Tab invokes a focus event (but no keyboard events)
<jcraig> https://
Matt_King: I think how your example is similar to what's not spec'd for mobile Safari. But the intrinsic nature of this proposed user agent requirement, how is it intrinsically different from the other UA requirements that are already in ARIA that somehow related to focus. For example, the whole section around managing focus, and the spec portion around aria-activedescendant
Sarah: we have authoring requirements for what keyboard behavior should go with certain roles; but I don't believe we have anywhere where we say user agents should change event'ing (or built in non-semantic behavior based on ARIA)
… stuff like what the keyboard should be, or what events should fire. I suppose we have focus events firing for activedescendant
jcraig: focus events are tied to DOM spec, not ARIA spec
Sarah: that's the difference, it's not an a11y API thing, it's a DOM thing
Matt_King: Are we concerned about that here, is this somehow the scope of ARIA? It doesn't feel like it is (beyond the scope of ARIA)
Jacques: I'm wondering how we felt about the direction the PR is taking, and whether ARIA can specify this (focus behavior which we haven't been able to agree on)
<spectranaut_> ack jcraig
jcraig: the focus behavior in response to aria-actions is undefined at this point because there's scenarios where it seems logical to change focus and others where it is not; perhaps we should list all of those and make some definitive distinctions and make UA/AT can align on right behavior
… Alice (Boxhall) and I years ago were discussing synthesized events in the context of the AOM explainer link above
… things like click or press for all elements when AT triggers this hasn't been specified but they work. Another example is blur not being caused by AT, but by a subsequent focus event for an element
increment/decrement can trigger keyboard up/down events depending on the context. Escape is another great example, various mainstream devices as well as AT to have a "get out of this view" (VO has z-scrub gesture that synthesizes Escape key) My point in mentioning this table is that it could potentially live in the ARIA spec, and if so, that may be a good landing spot for the focus behavior that ends up being decided for aria-actions
Jacques: can the aria-actions meet separately and hash this out?
Matt_King: perhaps a deepdive?