17:00:56 RRSAgent has joined #aria 17:01:01 logging to https://www.w3.org/2026/07/02-aria-irc 17:01:01 RRSAgent, make logs Public 17:01:02 Meeting: ARIA WG 17:01:08 chair: ValerieYoung 17:01:08 agendabot, find agenda 17:01:08 spectranaut_, OK. This may take a minute... 17:01:09 agenda: https://www.w3.org/events/meetings/690d057f-db6d-4169-b13f-68d7f1336b59/20260702T130000/ 17:01:09 clear agenda 17:01:09 agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-06-25+repo:w3c/aria&type=Issues 17:01:09 agenda+ -> WPT Open PRs https://tinyurl.com/wpt-a11y 17:01:12 agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates 17:01:14 giacomo-petri9 has joined #aria 17:01:16 giacomo-petri9 has left #aria 17:01:19 agenda+ -> Add explicit language and direction metadata to AriaNotificationOptions https://github.com/w3c/aria/issues/2828 17:01:20 agenda+ -> Allow treeitems to omit groups by specifiying aria-level, aria-posinset, and aria-setsize https://github.com/w3c/aria/pull/2091 17:01:23 agenda+ -> aria-actions: handling focus when actions are synthetically triggered https://github.com/w3c/aria/issues/2691 17:01:26 agenda+ -> Impact of AI technologies on Accessible Rich Internet Applications Working Group's mission https://github.com/w3c/aria/issues/2796 17:01:45 giacomo-petri has joined #aria 17:02:00 HaTheo has joined #aria 17:02:09 pkra has joined #aria 17:02:09 Stefan has joined #aria 17:02:13 present+ 17:02:20 katez has joined #aria 17:02:23 filippo-zorzi has joined #aria 17:02:24 present+ 17:02:26 present+ 17:02:31 present+ 17:02:31 sarah has joined #aria 17:02:39 present+ 17:02:41 present+ 17:02:47 present+ 17:03:02 present+ 17:03:08 scribe: Rahim 17:03:50 zakim, next item 17:03:50 agendum 1 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-06-25+repo:w3c/aria&type=Issues -- taken up [from agendabot] 17:03:50 I can't comment on that because it doesn't look like a github issue to me. 17:04:20 siri has joined #aria 17:04:21 Jacques has joined #aria 17:04:26 jamesn has joined #aria 17:04:29 jcraig has joined #aria 17:04:30 present+ 17:04:38 present+ 17:04:38 agenda? 17:05:23 giacomo-petri: I went through the allowed a11y roles; suggestion #1 is more obsolete compared to the others. I tried using a11y children to clarify, for example, generic intervening (and role=none) are also allowed. Perhaps we can discuss in the next meeting 17:05:35 present+ 17:05:43 ...right now, I'm keeping it as is but potentially, it could be a point of discussion 17:06:09 pkra: I think it should be split up into an editorial issue, and author MUST statements 17:06:31 giacomo-petri: This one is editorial; assuming children is the same as "accessibility children" which is a point of discussion 17:07:04 pkra: I've already taken a look; it's about the move towards using "accessibility children" which we (ARIA WG) haven't gone through the move of cleaning it up comprehensively in the spec 17:07:23 spectranaut_: Can look at this as editorial 17:07:28 HaTheo: I'm happy to take a look 17:07:49 benbeaudry has joined #aria 17:07:52 https://github.com/w3c/aria/pull/2833 17:07:52 present+ 17:08:05 present+ 17:08:11 HaTheo: ARIA PR #2833 is editorial 17:08:23 spectranaut_: I'll take a look at merge it since it's core-aam 17:08:26 zakim, next item 17:08:26 agendum 2 -- -> WPT Open PRs https://tinyurl.com/wpt-a11y -- taken up [from agendabot] 17:08:26 I can't comment on that because it doesn't look like a github issue to me. 17:10:26 HaTheo: For WPT #60778, I looked at CDP and their API, and support in Chrome for getting a11y properties. I added the accessibility protocol part, and standard functions you call in a test to add those. Chrome is actually doing well, just a couple places I saw errors 17:10:39 ...saw aria-actions is working in Edge 17:10:50 ...please take a look at it, but if it's duplicative let me know 17:11:33 spectranaut_: I didn't know that Chrome DevTools Protocols (CDP) was available 17:11:48 HaTheo: Can add indication that it's experimental but it does seem to run tests pretty well 17:12:00 CurtBellew has joined #aria 17:12:21 present + 17:12:29 jcraig: For WPT #60533: we've got two positive reviews but Ben had a comment on something that wasn't responded to. Is that resolved/updated? 17:13:05 HaTheo: I haven't resolved that yet, happy to uncomment it. There's not support for any browser yet (toggle pattern) 17:13:13 spectranaut_: Let's leave the assert(), it's OK for the test to fail 17:13:21 HaTheo: I'll make an amendment to my last commit and add this back in 17:13:49 HaTheo: The Invoke pattern is an interesting one, I'll take a look at that one later 17:14:34 spectranaut_: Did you run these tests locally as well, Ben? 17:14:49 benbeaudry: No, but found a bunch of issues in Chromium (already filed a bug) 17:15:19 sarah: We should consider the possibility that the spec also has issues; e.g., for toggle, wrong semantics on menuitemradio 17:16:02 jcraig: WPT #60504 may be ready to merge 17:16:29 HaTheo: I've simplified this one, since we can add things in later 17:16:38 spectranaut_: I'll look and merge 17:17:54 jcraig: For WPT #59768, I'm still reviewing this one from Tyler. It's getting close 17:18:03 spectranaut_: Ping me when it's ready 17:18:18 jcraig: We have a 2nd reviewer, but I was going to merge it when it's ready 17:18:45 ...we've got two approvals on yours WPT #60410 17:19:04 spectranaut_: I haven't merged this one yet because I wanted to open bugs on the browsers and then merge it. But no reason to necessarily do that 17:19:17 ...thanks for pinging me, I think we can merge this 17:20:04 Daniel: I used to be a WPT repo admin, but not anymore 17:20:42 zakim, next item 17:20:42 agendum 3 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 17:20:42 I can't comment on that because it doesn't look like a github issue to me. 17:21:48 jcraig: I may have a potential one regarding aria-actions and focus which has outstanding questions. We also have 3 implementations so seems like a good opportunity for a deep dive 17:22:11 spectranaut_: Did we discuss ARIA #2791 in a meeting, Matt? 17:22:37 Matt: There's a lot of history here that started with overscroll discussion. This is one of those issues where we need to get NVDA reps involved if we're going to come up with any agreement on what we're going to put in spec 17:22:54 spectranaut_: This is a matter of getting the right folks in the room. Has anyone started that email thread? 17:23:03 Matt: Is that something you or James N. would do? 17:23:04 q+ 17:23:29 ...as long as we have a time horizon for this, we should have some kind of plan 17:23:51 jamesn: Sure (I can do this) 17:24:06 ...I'll ping you (Matt) to formulate what we want to say/ask 17:24:12 q- 17:24:21 agenda? 17:24:41 zakim, take up item 6 17:24:41 agendum 6 -- -> aria-actions: handling focus when actions are synthetically triggered https://github.com/w3c/aria/issues/2691 -- taken up [from agendabot] 17:25:07 present+ 17:25:25 spectranaut_: What are the next steps? James C. was suggesting a deep dive that Jamie Teh could attend 17:25:43 sarah: Just a deep dive, or perhaps a call? 17:26:06 jcraig: The best time would be 3 or 4PM PT (and preferably not on Friday, July 3 is a US holiday) 17:27:01 spectranaut_: Can someone respond and propose a time? I'm OOO next week 17:27:41 Matt: Can we come up with a couple proposed times and put them in the email thread to make sure they work for Jamie Teh. I'm available Mon/Tues next week, the next following week is more flexible 17:27:44 I'm on an engineering rotation 9-5, so the later in the day the better, but I can make things work if needed. 17:28:13 jcraig: Tyler Wilcock is OOO, but I'd like Dominic Mazzoni on there 17:28:50 sarah: Attendees will be James Craig, Dominic Mazzoni, Matt King, Jacques Newman, myself and Jamie Teh 17:29:11 zakim, take up item 4 17:29:11 agendum 4 -- -> Add explicit language and direction metadata to AriaNotificationOptions https://github.com/w3c/aria/issues/2828 -- taken up [from agendabot] 17:30:31 Clay: I added this to the agenda, ran over in triage last week. Sarah had commented (thanks), and I as well pulling in previous context. Wanted to open it to the ARIA WG to understand the ask, to see if this is something we want/could support. Proposal is to add a lang attribute or action along with ariaNotify calls to designate a different language than the sending element 17:30:50 q+ 17:30:52 ...don't see a use case for this, and why we want messages to have arbitrarily different language then sending element and why we would want this 17:31:19 jcraig: You can also modify the lang of the sending element 17:31:26 ack Jacques 17:31:37 Clay: There are other options without additional customization 17:33:22 q+ 17:33:24 jcraig: Don't agree with the addition of adding a text direction (there's no ARIA text direction property somewhere else is there). We're going to decline this request (don't need it, other ways to do it). Calling this as we consider future expansions, and avoiding ARIA (e.g., should just be text-direction, or dom-text-direction, and not include ARIA) 17:33:30 ack Daniel 17:34:32 Daniel: We shouldn't close the issue yet; based on the group's consensus that it's not needed, I would expect the issue to include rationale as to why (e.g., Sarah has explained). We should comment on the alternative ways to do that 17:34:45 spectranaut_: I won't close, I will comment noting if it's enough that there's other ways to do this 17:34:51 zakim, next item 17:34:51 agendum 3 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 17:34:51 I can't comment on that because it doesn't look like a github issue to me. 17:34:59 zakim, next item 17:34:59 agendum 3 was just opened, Rahim 17:35:05 zakim, take up item 5 17:35:05 agendum 5 -- -> Allow treeitems to omit groups by specifiying aria-level, aria-posinset, and aria-setsize https://github.com/w3c/aria/pull/2091 -- taken up [from agendabot] 17:35:19 d/Don't agree with the addition of adding a text direction/For future reference, even if we were to add a text direction, we should not prefix ARIA here as proposed AriaTextDirection/ 17:36:05 s/We're going to decline this request /From the discussion, it sounds like we're going to decline this request / 17:36:22 HaTheo: I wrote some tests and in this case, tested if the level was respected; it is, but it doesn't end up in a hierarchy. This will dictate if the other test will go from being a draft to another PR 17:36:42 ...I don't know if the hierarchy is important; if it is, we probably need to file a test and bugs on browsers otherwise, this one is good to go 17:36:52 spectranaut_: Is it a flat tree? If you look at the children, they're not re-arranged 17:37:03 s/should just be text-direction, or dom-text-direction,/should just be TextDirection dir, or actually DOMString dir,/ 17:37:26 Matt_King has joined #aria 17:37:30 present+ 17:37:36 q+ 17:37:46 sarah: I was comparing the a11y API output vs. a thing done with children, and I think that was the same. In the platform a11y API, you don't get hierarchy 17:37:57 ...can just ensure that setsize/posinset/level are mapped correctly 17:38:17 HaTheo: I can find other examples in WPTs; in my manual testing across Windows, Mac, Linux and different screen readers, and I had no issues in having level read out 17:38:29 sarah: I also have a flat tree example, but it's not much more complex than what you already have 17:38:32 https://storybooks.fluentui.dev/react/?path=/docs/components-tree--docs#flat-tree 17:38:44 HaTheo: If you can send me an example, I'm happy to use that 17:39:04 ack Matt_King 17:39:39 q+ 17:40:20 Matt: When I was looking at this PR, if there is a repair one thing I don't see here is what the author requirements are for setting posinset. I don't know what happens when somebody numbers their posinset for the entire tree, e.g., 100 items that aren't all at aria-level=1 but you do aria-posinset at different values. Does that override what browsers calculate? 17:40:53 ...when you get to a treeitem in a subgroup, you're used to hearing item #1 in the subgroup. The spec may not say it's a mistake, can't find where in spec it tells authors how to make it work for users 17:40:55 q+ 17:41:07 ack sarah 17:41:35 sarah: That's not different from how it works now; even now, you can override how it works for posinset/setsize. If you're in a tree, you could have linear numbering and then jump to something like 150 17:41:44 q+ to discuss the history of why this level/set exists outside the parent/child relationship 17:41:54 ...that's why you would define posinset/setsize, it's an intentional part of the feature. Authors can mess it up 17:42:42 Matt: The part that's confusing is if the author doesn't want to put in in groups and use posinset instead, they have to have some kind of understanding what the requirements are for posinset to work the way we (ARIA spec) intend 17:43:12 ack jcraig 17:43:12 jcraig, you wanted to discuss the history of why this level/set exists outside the parent/child relationship 17:43:13 ...I can't find where it says in spec where browsers do and what's expected 17:43:36 jcraig: I was going to talk about the history of why this pattern was done. It's possible Matt was in the group 17:44:28 ...at the time, there was no such thing as allowing re-rendering/re-ordering of child nodes (used to use the phrase "don't cross the streams" as people thought it would cause looping issues). We then figured out ways to avoid that problem, and now we can re-order items in the a11y tree separate from the DOM 17:44:56 q+ 17:45:37 ...this a11y pattern was developed prior to this evolution. So, aria-level/aria-posinset was a way to convey to ATs that there were re-usable elements that were in a different order and nesting for patterns such as trees (but not expanded out to the entire DOM since it's a set). Even though these (elements) end up being sibling/children, ATs can convey them accurately 17:45:45 ...the fact it's not listed is probably just an editorial oversight 17:45:45 ack sarah 17:46:29 sarah: The reason they wanted a flat tree at Microsoft is due to virtualization which is easier and more performant. It's more likely you'd be heavily managing setsize/posinset/level in a flat tree, rather than a nested/hierarchical one 17:46:50 ...even in a nested one, need to know the same things so I'm all for adding more information on how to do that but don't think it should be a gate on this specific PR 17:47:54 Matt: I may need to re-read the whole treeitem thing. The structure may be explained in a non-normative way 17:48:39 +q, there was another issue around posinset/setsize for tree items, I am not finding it but I skimmed it and assumed that's what Matt was bringing up 17:48:42 ...if you're not using groups, then it seems that it would have to be a normative requirement that you specify posinset/setsize. If it's normative, in that case, then doing that without a normative explanation of what those values should be (how to calculate them as an author) seems like it would be necessary 17:49:19 sarah: There was never anything in the spec that said you couldn't do this; and in fact, we do this relatively widely because it's a lot more performant for visualization. It's not forbidden by spec 17:49:52 ...this PR adds clarity, and a browser MUST for calculating aria-level from the DOM (if nested) and also adds an author MAY noting that they can do this. But it doesn't change existing spec MUST/MAYs 17:50:00 ...it's not changing any existing requirements 17:50:35 jcraig: As Sarah has mentioned, there are MUST/SHOULD requirements in spec that are tied to language that says "if all items are not present in the document structure..."; if you think you found some RFC MUST/MAY/SHOULD, I would encourage you to file a bug 17:50:44 Matt: Based on what Sarah said, we can make this a separate issue 17:50:56 HaTheo: Wasn't there an issue around standardizing posinset/setsize? 17:51:29 Matt: Yes, that's the deep dive; that one is for areas where it's not clear like menus. For trees, I don't think there's any questions since screen readers have always done the same thing 17:52:07 jcraig: Tree controls in Mac are a type of table (collapsible tree table, essentially a tree grid) 17:52:16 zakim, take up item 6 17:52:16 agendum 6 -- -> aria-actions: handling focus when actions are synthetically triggered https://github.com/w3c/aria/issues/2691 -- taken up [from agendabot] 17:52:23 zakim, take up item 7 17:52:23 agendum 7 -- -> Impact of AI technologies on Accessible Rich Internet Applications Working Group's mission https://github.com/w3c/aria/issues/2796 -- taken up [from agendabot] 17:53:10 q+ 17:53:12 spectranaut_: If anyone has any thoughts, you can put in this issue or we can talk about it now. Daniel? 17:53:37 Mac AppKit tree controls are effectively a type of single column collapsible table (essentially a single-column tree grid) 17:53:55 s/Mac AppKit tree controls are effectively a type of single column collapsible table (essentially a single-column tree grid)// 17:54:15 s/Tree controls in Mac are a type of table (collapsible tree table, essentially a tree grid)/Mac AppKit tree controls are effectively a type of single column collapsible table (essentially a single-column tree grid)/ 17:54:49 Daniel: This is related to how it might affect the mission of the ARIA WG; the big question is how everyone is using AI. There's a danger of using ARIA to "please agents", and how LLM makers are portraying ARIA. A pro could be that agents are able to remediate UIs based on knowledge that can be scraped from specs and other resources like APG 17:55:03 ack smockle 17:55:45 q+ 17:55:53 Clay: Practical day to day for how we execute this work, we briefly discussed Zoom AI note-taking. I've been on calls where not everything is minuted, how can we more careful on things being stricken/not minuted 17:55:53 ack Jacques 17:56:23 Jacques: +1, in the groups I'm in that use AI note-taking, not as useful as human transcription. For now, we should use the best tools (i.e., human notetaker) 17:56:43 q+ 17:57:03 q+ 17:57:11 jcraig: +1, my experience with auto transcription is that for general conversation is good but technical/domain-specific conversations, you need domain-specific training data (true for ARIA WG) 17:57:20 ack JohnJansen 17:57:23 q+ 17:58:11 JohnJansen: Some WGs don't allow AI transcription due to government contracts. I've been experimenting with a tool that listens to active Zoom tab, and types into IRCCloud but doesn't submit so types for you but allows you to review before submitting (doesn't identify people as well) 17:58:27 ...could be something that works for the ARIA WG 17:58:58 that sounds interesting to me, again, I'm for using the best tools available. 17:58:58 jcraig: That is how human professional transcribers work today; they use AI-based transcription and augment on the fly (human + machine based transcription) 17:58:59 ack Matt_King 17:59:43 Matt: Back to Daniel's issue and our mission, one possible solution to this issue is to determine that we don't need to make any modifications to the ARIA WG's mission, and what it might mean to come to the conclusion that AI doesn't change that mission 18:00:22 ...we're being told to think of agents as "people-like"; but as a consequence of supporting people, we're also supporting agents perhaps but this may be a big logical leap 18:00:26 q- 18:01:07 Daniel: I don't think we should be changing the mission; the agent aspect you (Matt) mentioned is something we should pay attention to. We want to serve the agents and please them but we may be perpetuating bad uses cases of ARIA 18:02:24 Matt: For example, we have an open PR in the Authoring Practices Guide (APG) to make an MCP (Model Contextual Provider/Protocol) which we summarily decided against 18:08:44 rrsagent, make minutes 18:08:46 I have made the request to generate https://www.w3.org/2026/07/02-aria-minutes.html Rahim 20:51:03 github-bot has joined #aria