16:58:00 RRSAgent has joined #aria 16:58:04 logging to https://www.w3.org/2025/07/03-aria-irc 16:58:04 chair: ValerieYoung 16:58:08 RRSAgent, make logs Public 16:58:09 Meeting: ARIA WG 16:58:30 agendabot, find agenda 16:58:30 spectranaut_, OK. This may take a minute... 16:59:01 Sorry, I did not find an agenda. 16:59:50 filippo-zorzi has joined #aria 17:00:31 agendabot, add item [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues) 17:00:31 spectranaut_, sorry, I don't understand "add item [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues)". Try "agendabot, help". 17:00:39 agendabot, additem [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues) 17:00:40 spectranaut_, sorry, I don't understand "additem [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues)". Try "agendabot, help". 17:00:45 katez has joined #aria 17:01:12 zakim, add item [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues) 17:01:12 I don't understand you, spectranaut_ 17:01:28 Adam_Page has joined #aria 17:01:35 Francis_Storr has joined #aria 17:01:39 zakim, item+ [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues) 17:01:39 I don't understand you, spectranaut_ 17:01:50 present+ 17:01:59 sarah has joined #aria 17:02:03 present+ 17:02:05 present+ 17:02:10 present+ 17:02:17 present+ 17:02:20 agendabot, find agenda 17:02:20 spectranaut_, OK. This may take a minute... 17:02:21 Sorry, I did not find an agenda. 17:02:35 TOPIC: [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-06-26+repo%3Aw3c%2Faria&type=Issues) 17:02:40 https://www.w3.org/guide/meetings/zakim.html#agendaplus 17:02:57 Mario has joined #aria 17:03:06 present+ 17:03:17 ChrisCuellar has joined #aria 17:03:23 Scribe: Rahim 17:03:29 present+ 17:03:42 pkra has joined #aria 17:03:45 present+ 17:03:49 front-endian-jane has joined #aria 17:04:05 TOPIC: [WPT Open PRs](https://bit.ly/wpt_a11y) 17:04:23 spectranaut_: Doing new issue triage every other week, none for today. No new PRs either 17:05:02 ...no new WPT tests either 17:05:29 rahim: jamie teh raised an issue related to a crash for gecko when a role fallback but the second role is capitalized 17:05:56 rahim: I'm writing tests for it 17:06:31 zakim, next item 17:06:31 I do not see any more non-closed or non-skipped agenda items, Rahim 17:06:33 TOPIC: [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) 17:07:15 spectranaut_: Table deepdive is coming up in 2 weeks. Anything else we should cover? (*no items mentioned*) 17:07:18 TOPIC: [Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem](https://github.com/w3c/aria/pull/2483) 17:07:46 spectranaut_: Added my Peter if he'd like to add anything 17:08:22 CurtBellew has joined #aria 17:08:30 present+ 17:08:38 present+ 17:09:05 pkra: Giacomo isn't around. I wanted to bring this to the attention of the group; we'd touched on the idea of equivalent of HTML content model (i.e., parsing rules). I feel this issue touches on this, and I was reviewing Giacomo's PR which tries to capture the reality/complexity of things that may have a group alongside the intended children, e.g., menu item in a menu. Can have a group, or many groups 17:10:03 ...not so long ago, decided menu item is a child of menu but not necessarily which led to questions around content model. Reviewing this PR and language is complicated trying to capture behavior of menus in particular; trees/menus are generally challenging 17:11:10 ...language is not always precise. From CSS, use "donut scoping" in order to simplify language. For example, in this PR, it adds detailed language around specific requirements for this scenario which is undesirable from an editorial perspective, can be confusing 17:11:38 q+ 17:12:35 ...want to talk what's allowed between menu and menu item (i.e., donut scope), but not going beyond that. I've been thinking about this, and made comments to the PR to come up with better language. One thing Giacomo added was definition of accessibility ancestor (which was lacking before) which is helpful in terms of scoping 17:13:30 spectranaut_: I think I understand the issue but in the example you (Peter) provided, i.e., "authors must limit descendants to...." (look at PR for exact language), are you allowed to have a group within a group? 17:13:36 StefanS has joined #aria 17:13:38 pkra: I believe so, such as submenu structure 17:13:52 present+ 17:14:49 spectranaut_: the reason we introduced accessibility child to clarify allowed children; saying that the next semantically significant node has to be e.g., group/menuitem/separator/etc. 17:15:09 pkra: yes, but once you're in a group, you have to clarify group in a menu so there may be additional restrictions to children 17:15:43 pkra: in this particular section (of the PR), don't think we need accessibility descendant, may just need to specify accessibility children 17:17:00 ...what I'm looking for, wondering if this is an opportunity to explore a better nomenclature to move towards a content model, i.e., a language we can better phrase/define things 17:17:33 spectranaut_: you mentioned "donut scoping", is that from CSS? 17:17:53 Jane: it doesn't come up often, but it is a term that has been used 17:18:27 pkra: don't feel strongly on what we call it (content model) 17:18:47 Jane: is confusing to explain accessibility child vs. descendant, look into making the wording easier to understand as a bare minimum 17:19:34 pkra: started adding exceptions such as presentation/none; but we want to expand things such as aria-actions. Want better language to better define/surface these types of models 17:19:49 q+ 17:20:02 ack spectranaut_ 17:20:04 ack sarah 17:20:52 sarah: rather than donut scoping, we may want recursion which doesn't work well in specs. The recursion bit helps specify that there are multiple groups which is difficult to convey in terms of language. For aria-actions, thinking of globally allowed children (e.g., scrollbar which should be globally allowed) 17:21:40 ...we have a bunch of things which are allowed a11y children; for scrollbar, anything can scroll. In this sense, aria-actions allowed anything as a11y children 17:22:52 spectranaut_: another thing in the language we used for accessibility child: we use the word "intervening" 17:23:30 pkra: presentation/none are globally allowed children; can simplify language and get rid of redundancy. Similarly, groups are like that because many roles allow intervening groups 17:23:40 spectranaut_: are there some parent/child relationships that don't allow intervening groups? 17:24:10 sarah: it can be different; listbox can have one group intervening as opposed to menu/tree/treegrid where you can have nested hierarchies 17:24:15 q+ to be a wet blanket (and provide no solution) about performance with allowing infinitely deep nesting.... 17:24:46 pkra: maybe even tables (thinking of colspan/rowspan); but lists, you wouldn't want nested groups in lists which may be desirable for styling purposes 17:24:58 Jane: allowed on definition lists 17:25:16 ack jcraig 17:25:16 jcraig, you wanted to be a wet blanket (and provide no solution) about performance with allowing infinitely deep nesting.... 17:26:12 jcraig: the problem with allowing infinitely deep nesting of generics, more of a practical issue. Especially because there are many rules of ARIA where rules determine if something is generic 17:27:27 ...as rules get more complex, causes implementations to become more complex which leads to things running more slowly. It would behoove use to come up with reasonable expectations, e.g., if you need to use infinitely deep generics, could suggest that the author put some explicit value (may not solve the problem of div-itis). But could make implementations faster, such as ignoring particular subtree 17:27:52 Jane: is what you're suggesting such as pulling arbitrary number, e.g., 100 divs but 101st 17:27:57 jcraig: specifically not suggesting that 17:29:08 ...VoiceOver users start noticing performance problems at 40ms which is surprisingly fast. For this 100 div solution, and other deep div nesting, it contributes to performance problems 17:29:32 q+ 17:29:46 Jane: curious about the performance problems; is it the spec or developer's responsibility? Depending on how many generics you can have listed. If you write inefficient code, that's on the developers 17:31:29 jcraig: there isn't some specific spot where performance becomes an issue, it's more of a cumulative issue. The other key difference is that this isn't a performance problem for someone writing inefficient code; e.g., one website writes inefficient code and it only affects that page. It's because we're allowing rules that need to be executed, and supporting implementations to be slower 17:31:34 q+ 17:33:00 sarah: in terms of screen reader performance, curious about the various ways someone can do that while conforming with the spec. I have a bunch of options, but I'm not sure if we've ever disallowed specific things because of performance (e.g., many many live regions on a page, or a really big table). So, I'm hesitant to use that as a reason to not do that, but get your point that it can slow things down for everyone 17:33:19 ack me 17:33:21 ack pkra 17:34:02 s/It's because we're allowing rules that need to be executed, and supporting implementations to be slower/It's because the spec add rules that need to be executed on all pages, and therefore implementations will be slower on all pages, not just the inefficient pages./ 17:34:09 pkra: I wanted to acknowledge the importance of topic, and intervening generics is already in the spec. What I wanted to bring to the agenda is simplifying language in spec for situations where we want to provide certain intervening elements for structural reasons, to help people understand spec and clearer for us to reason about the spec 17:34:28 ...maybe we can do a deepdive eventually on the content model stuff, but I'm not currently ready for that 17:34:36 s/spec add rules/spec adds rules/ 17:35:21 pkra: did people see Steve Faulkner's blog post? He had a conversation with Jamie Teh, and he wrote on the old problem of exposing content under an aria-label element. Is this something we want to talk about at some point 17:35:56 q+ 17:35:58 ...putting aria-label on a link, but link has other stuff (i.e., visible content) so visible content never gets exposed 17:36:34 https://html5accessibility.com/stuff/2025/06/12/accname-unclarified/ 17:37:05 pkra: touches on content model (flow/phrasing content) 17:37:29 sarah: if we changed it, it would be breaking a lot of stuff. People mess it up, but it's also used and purpose which is my concern 17:37:54 s/but it's also used and purpose which is my concern/but it's also used on purpose which is my concern/ 17:38:13 pkra: I'm wondering if there's more hiding underneath this discussion 17:38:16 ack me 17:39:15 jcraig: SVG images is an interesting case because some SVGs use title; if that was made accessible and browsers see more of them, kind of a chicken/egg problem. Only supported on inline SVGs at the moment, but most authors don't know about that functionality 17:39:33 pkra: I'll file an issue 17:40:04 spectranaut_: feel free to use the remaining time to review issues/PRs please 17:43:49 rrsagent, draft minutes 17:43:50 I have made the request to generate https://www.w3.org/2025/07/03-aria-minutes.html Rahim 17:46:44 ChrisCuellar has joined #aria 18:12:41 ChrisCuellar has joined #aria 20:49:04 ChrisCuellar has joined #aria 21:32:07 ChrisCuellar has joined #aria 21:48:34 ChrisCuellar has joined #aria