16:51:18 RRSAgent has joined #aria 16:51:22 logging to https://www.w3.org/2025/04/24-aria-irc 16:51:22 RRSAgent, make logs Public 16:51:23 Meeting: ARIA WG 16:51:34 agendabot, find agenda 16:51:34 jamesn, OK. This may take a minute... 16:51:34 agenda: https://www.w3.org/events/meetings/ef1f2d62-1c5d-4300-916c-b54d87c3ad98/20250424T130000/ 16:51:34 clear agenda 16:51:34 agenda+ -> New Issue Triage https://bit.ly/444j9sh 16:51:35 agenda+ -> New PR Triage https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-04-17+repo%3Aw3c%2Faria&type=Issues 16:51:38 agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y 16:51:40 agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates 16:51:43 agenda+ -> Children Presentational discussion https://github.com/w3c/aria/issues/2509 16:51:46 agenda+ -> PR Reviews https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc+ 16:52:20 regrets+ CurtBellew 16:52:28 regrets+ BryanGaraventa 16:52:34 filippo-zorzi has joined #aria 16:59:44 Francis_Storr has joined #aria 17:00:27 ChrisCuellar has joined #aria 17:00:49 giacomo-petri has joined #aria 17:00:57 present+ 17:01:07 present+ 17:01:23 present+ 17:02:06 melsumner has joined #aria 17:02:41 present+ Daniel 17:02:57 present+ 17:03:04 aardrian has joined #ARIA 17:03:05 pkra has joined #aria 17:03:09 present+ 17:03:35 scribe: Rahim 17:03:39 zakim, next item 17:03:39 agendum 1 -- -> New Issue Triage https://bit.ly/444j9sh -- taken up [from agendabot] 17:03:40 present+ 17:04:01 present+ 17:04:08 present+ 17:04:45 katez has joined #aria 17:04:50 present+ 17:04:51 scott has joined #aria 17:04:51 Adam_Page has joined #aria 17:04:57 present+ 17:05:05 present+ 17:05:15 ugh, sorry. I have to drop off already -- sorry for not really being here today. 17:05:41 jamesn: ARIA #2516, 2515 are both editorial; for ARIA #2514, can come up with terminology (seems like something a non-editor could do but same across specs) 17:05:52 Daniel: I can self-assign myself (to ARIA #2514) 17:05:56 zakim, next item 17:05:56 agendum 2 -- -> New PR Triage https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-04-17+repo%3Aw3c%2Faria&type=Issues -- taken up [from agendabot] 17:05:57 filippo-zorzi has joined #aria 17:06:08 zakim, close this item 17:06:08 agendum 2 closed 17:06:09 I see 4 items remaining on the agenda; the next one is 17:06:09 3. -> WPT Open PRs https://bit.ly/wpt_a11y [from agendabot] 17:06:11 zakim, next item 17:06:11 agendum 3 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot] 17:06:15 present+ 17:06:40 jcraig: Nothing on my end. I will be done (with a PR) by the end of the call 17:06:46 zakim, close this item 17:06:46 agendum 3 closed 17:06:47 I see 3 items remaining on the agenda; the next one is 17:06:47 4. -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates [from agendabot] 17:06:51 zakim, next item 17:06:51 agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 17:07:25 jamesn: have we already discussed tables without table headers, or is this new? 17:08:03 aardrian: I did weigh in on a table headers GitHub issue relatively recently, but not this one so new to me. To manage expectations, I do want to table deepdives but no capacity until May 17:08:11 q_ 17:08:12 q+ 17:08:35 ...want to have stuff buttoned up so I can be prepped for TPAC conversations 17:08:50 keithamus: on my docket to explore as well, will get to it. Before TPAC is a good deadline but worth deferring until then 17:09:26 jamesn: worth pointing AI bot to (browser) codebases of tables as a starting point 17:09:38 Siri has joined #aria 17:09:52 present+ 17:10:03 ....myself and Val are out for various weeks in June, so we may be cancelling a few meetings in June. Daniel M. could run them but may be cancellations in June/July (due to US holiday) 17:10:28 ...depends on business we have to close them 17:10:31 zakim, next item 17:10:31 I see a speaker queue remaining and respectfully decline to close this agendum, Rahim 17:10:41 ack keithamus 17:10:43 zakim, next item 17:10:43 agendum 5 -- -> Children Presentational discussion https://github.com/w3c/aria/issues/2509 -- taken up [from agendabot] 17:11:40 jamesn: extra discussion took place last week. Pointed out to Wilco that we don't want to deprecate across the board. Wilco doesn't know what a more specific proposal would be, i.e., presentational children is a mistake. Can't think of a more narrow list of roles 17:12:06 ...in the ARIA Editor's call, we discussed it. I wanted to take a look at what we say about presentational children in the (ARIA) spec 17:12:10 cyns has joined #aria 17:12:21 cyns has left #aria 17:12:32 buttons inside of buttons should break your build, that's such a chaotic thing to do. 17:12:42 jamesn: *reading from ARIA spec section 5.2.9 Children Presentational* 17:12:58 cyns has joined #aria 17:13:08 ...make a user agent requirement that UAs expose them. Not sure if there is a listing in the spec of all roles that have children presentational 17:13:24 q+ 17:13:32 q+ 17:14:15 jamesn: there is a list with all roles that support children presentational 17:14:56 ...can't really think of how someone could put a child on a checkbox and make it useful. When I look through this list, can't think of a use for checkbox. Images, yes that happens often (are they really images, or interactive graphics) 17:14:58 q+ to ask does Wilco want some kind of interop decision across browsers on what to do for these roles? 17:15:38 Rahim: What's the difference between "children presentational" and "presentational children"? 17:16:34 jcraig: children presentational is an attribute of the container, e.g., a progress bar. Presentational children is a description of any DOM elements that are inside that container 17:17:16 ...sliders, scrollbars, separators (are examples that have presentational children) 17:17:32 Q+ 17:17:45 jamesn: how can the thumb of a slider have children? 17:18:14 jcraig: sometimes sliders have clickable areas inside slider tray; sometimes you can interact with slider/track/thumb separately 17:18:25 TBH we need research on this 17:18:36 jamesn: browsers may be correct that people want to have children on various things 17:18:37 ack Rahim 17:18:40 ack spectranaut_ 17:18:40 spectranaut_, you wanted to ask does Wilco want some kind of interop decision across browsers on what to do for these roles? 17:19:05 q+ 17:19:18 q+ 17:19:49 spectranaut_: I wanted to say that I think this request from Wilco is an interoperability-based one, i.e., can we (ARIA WG) help normalize a decision across browsers. WebKit seems most dissimilar so a question in part for WebKit and is it something that they (WebKit) is willing to change for better interoperability. If not, think about what the "MUST" statement here, e.g., removing children presentational from roles as James suggested 17:19:58 jamesn: Wilco would like all of them to be removed 17:20:21 spectranaut_: still think it's an interop problem. Does Chrome/Firefox expose presentational roles? button/image ones are obvious 17:20:28 ack spectranaut_ 17:20:40 jcraig: even the button one could be handled by actions, i.e., action on same element. Image is more "open" as explorable content 17:20:58 jamesn: when actions come, it allows these problems to be solved. People are doing this all the time even through they shouldn't be 17:21:20 ...e.g., on a card you can favorite it, all sorts of other things 17:21:39 ...(actions = aria-actions) 17:21:41 ack aardrian 17:22:19 aardrian: one of my concerns is that I've seen devs getting around ARIA convention. Need to look at accname spec and other things 17:22:23 ack keithamus 17:23:08 q+ 17:23:12 keithamus: in agreement with Val. Feels "scorched earth" to remove this...going back to spec, there is a SHOULD that should be changed to MUST defining carve outs that browsers make around presentational children, not container nodes but child nodes themselves so nice to have greater granularity there. Right step forward here 17:23:14 ack scott 17:23:32 q+ 17:23:34 I've seen devs use ARIA to get around HTML prohibition on nested interactives. Which results in unexpected output (HTML serializes, not nests). So I fear accName would need an update. 17:23:57 agree, aardrian 17:24:02 q+ to +1 scott's discussion of downstream AT support 17:24:22 scott: not just a browser interop (issue), but also that not all ATs/screen readers will handle this the same even through Firefox/Chrome would have made elements that are child presentational exposed in a11y tree doesn't mean items are consistently accessible by AT (depends on mode of navigation, e.g., focus/browser mode). For example, voice dictation features don't know what to do with nested interactives 17:24:22 q+ 17:24:33 ...nice to have browser interop, but not useful if the AT doesn't know what to do with it 17:25:58 ack me 17:25:59 ...not opposed to removing some of the child presentational bits but not ideal to do it across the board. Should take a measured approach to this. Also discussed with Aaron, part of this is that some of it was done for good reasons but perhaps it should not have been and get very specific about what elements have presentational children, their content model, etc. It seems that it's circling around the same topic, i.e., ARIA needs to be more 17:25:59 specific and carve out what rules we want for specific rules with some being forgiving to authors while others are more specific 17:27:15 jamesn: I wanted to ask Keith on changing SHOULD to MUST; is that something we have in the spec and carve outs where they (browsers) should expose presentational children? (Keith agrees)....sounds like being more specific about browser behavior, being consistent is good and we can get AT to support the cases that are supportable and don't worry about unsupported cases because browsers wouldn't be exposing them 17:27:20 q? 17:27:27 q+ matt 17:27:38 ack jcraig 17:27:38 jcraig, you wanted to +1 scott's discussion of downstream AT support 17:28:48 jcraig: Scott said most of what I wanted to do. Are we confident that we know all these scenarios to confidently include/exclude the currently presentational children? I'm not confident of that, i.e., making MUST statements. Going back to Scott's comment for native app UI with a button inside text field, but uncommon in native app UI to have interactive image (thus exposed as a container rather than image) 17:29:36 ...there's a cautiousness that I want to convey that if we change something, need to have AT buy in and not get rid of them entirely. Most of us agree that is "scorched earth" but also not adding a "MUST expose" elsewhere until we're confident most scenarios have been fully considered 17:29:53 ack mel 17:29:57 ...we can test the WPT side of things but can't necessarily test AT side of things, and don't have as much a direct relationship with AT vendors 17:30:18 melsumner: strong +1 to Scott's point on being more explicit. I think we need strong user research before doing this because devs do strange things all the time 17:30:37 q+ 17:30:43 ...if we can prove the correct/supported way to do something, need to provide patterns/guides for that instead of providing support for everything devs want to do 17:30:50 ack matt 17:31:44 Matt: I'm glad Scott mentioned interop and James' caution and Mel not having chaos. I think the cautious path forward with explicit action is, I would really like for us to define the AT test cases as we're going through and take them one by one. I would love to have patterns for test cases that we put into APG and test with ARIA-AT project. Both projects are pretty mature and we can do this to build data to make solid decisions 17:32:09 ...we also have in APG the ability to do experimental patterns. Could serve as test beds for developing the AT interop test cases that we want 17:32:13 ack me 17:32:18 q+ to say maybe we can include something like "MUST/MUSTNOT expose in these known scenarios, but MUST fall back to expose when encountering something unexpected (dev did something weird; err on the side of exposing the nodes)" 17:33:05 jamesn: I want to ask a question about where aria-actions is since it will solve a lot of these problems in a slightly different way. For many of these cases, aria-actions would help and would allow these things to be available if they're children of something. We may want to push that feature more rather than tackling this differently 17:33:05 ack jcraig 17:33:05 jcraig, you wanted to say maybe we can include something like "MUST/MUSTNOT expose in these known scenarios, but MUST fall back to expose when encountering something unexpected 17:33:08 ... (dev did something weird; err on the side of exposing the nodes)" 17:33:35 jcraig: as a response to aria-actions, Jamie/Matt King provided feedback on the PR. It's been open for awhile 17:33:36 actions https://github.com/w3c/aria/pull/1805 17:33:44 Matt: we have a lot of notes on that from TPAC 17:34:57 jcraig: maybe there's a scenarios where we say "must not expose children of these..." *if it matches known scenarios. However, if engine encounters something like an author error that results in it not being exposed, could err on the side of exposing what author did even if it means invalidating what the author did 17:36:07 ...don't see a reason to have something inside progressbar (children presentational in this instance seems fine) but if you put a focusable, or element with `button` role, could invalidate and keep `progressbar` role on container. Allows cautious approach of allowing author's intent to get to user without breaking the scenario (rather than hard and fast rule that something is a `progressbar` so don't expose anything beneath it) 17:36:30 keithamus: was a little concerned when you said "matches known scenarios" because these can be quite complex 17:37:04 jcraig: just certain rules we have in there (particularly "author error" scenarios where it can undo in the scenario). Thinking of scenarios where authors make errors on purpose which can be tricky 17:37:24 ...like a button inside textfield is a common one where ARIA is used (or button inside menu button). 17:37:51 jamesn: does that work (button inside text field)? 17:37:56 jcraig: works for native app UIs 17:38:05 jamesn: is button a sibling to it, rather than child? 17:38:17 aardrian: is a sibling in the DOM 17:38:31 ...those workarounds didn't work, or how user expected it to work 17:38:57 jcraig: that's a scenario that's limited to the web because the developer is used to that (rigid structure of web is limiting them) 17:39:27 jamesn: perhaps not a problem that needs solving since there is a way to do. In this example, it's solved by making it a sibling (rather than child) 17:40:07 ...people can do things incorrectly to achieve that pattern which causes a11y to break. If we can solve that common problem, we may make things better 17:40:33 ...if we can find a pattern where we can push through but needs thought/deliberation/testing 17:41:23 jcraig: I wonder if we're getting close to relying on AI to figure this out 17:41:27 q? 17:41:45 jamesn: conclusion is that we don't know what do? 17:42:21 melsumner: I disagree. I think we do know....need to document everything we know to say "yes" to this idea, then gaps can become apparent and can assign tasks, figuring out what we can/can't do 17:42:50 jamesn: can say to Wilco that we're not doing you're idea of your broad "open this up to everybody" but rather that we need specific patterns to address this 17:43:16 https://github.com/w3c/aria/issues/2509 17:43:18 melsumner: *volunteers to take a look at this issue now* 17:43:39 zakim, next item 17:43:39 agendum 6 -- -> PR Reviews https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc+ -- taken up [from agendabot] 17:44:54 jamesn: for ARIA #2037, is still in draft status with a lot of comments. Mel may not be comment at the moment, but was created by you....should it stay open or close? 17:45:10 melsumner: if there's too much disagreement, can close it. If it's about integrating feedback, I can do that 17:46:03 scott: I've worked on a few aria-hidden PRs; this issue was a related PR and re-used as much work as we did. But this PR might be handled by later PRs but please double-check on what needs to remain open (or split off into other PRs) but likely already taken care of 17:47:50 jcraig: for ARIA PR #2015, that sounds familiar. A long time ago in ARIA, there was a requirement for managing focus on toolbars which was a Windows-specific pattern that was removed. This PR may be follow-up from that where it wasn't corrected in one place (but was in another) 17:49:01 Matt: it was handy to have a list in spec for "Managing Focus" section but we also have those statements that are in those sections for the individual roles so seems like it's just a matter of keeping these two in sync? 17:49:08 jcraig: any objections to merging this right now? 17:49:24 Scott: I need to figure out why I said I did not agree with it. I did review it 17:50:14 jamesn: (Scott) if you can read through your comment, and work out what it was (that you disagreed on). Looks like some formatting-related conflicts to figure out as well 17:50:16 q+ 17:51:00 ...might have to re-do this PR based on the changes rather than trying to fix it 17:51:40 melsumner: I think this is one of the areas where the PRs tend to stuck for a year because some feedback that is outside the scope of PR, for better incremental progress, why not put that in a new issue so as not to block incremental update for PR 17:52:22 jcraig: for this one, if we have two reviewers on what is effectively an errata change, it can be merged. But for prose changes (based on Scott's comments), that deserves another review 17:53:00 Scott: not that I disagreed with the change, could also negatively affect something else. Prefer for it to be all done at once, rather than a spec change that causes downstream changes 17:53:05 ack giacomo-petri 17:53:56 giacomo-petri: I agree with Scott that this PR introduces new issues but not opposed to merging. May confuse authors that they can handle focus within menu/listbox, etc. E.g., use `activedescendant` to manage focus via focus on container 17:54:20 Matt: managing focus can be roving `tabindex` or `aria-activedescendant` 17:54:44 Scott: but says authors can manage focus OR use `activedescendant` 17:55:46 q? 17:55:51 Matt: introductory text content needs a bit of tweak (for clarification around focus management techniques) 17:56:20 jamesn: Scott, you'll work out what the disagreements are (*Scott agrees*) 17:58:08 s/ do want to table deepdives/ do want to do table deepdives 17:58:33 s/do want to table deepdives/do want to do table deepdives 17:59:16 rrsagent, draft minutes 17:59:17 I have made the request to generate https://www.w3.org/2025/04/24-aria-minutes.html Daniel 17:59:37 s/depends on business we have to close them/depends on business we have to cancel them 18:01:26 s/is willing to change for better interoperability/are willing to change for better interoperability 18:02:04 s/could be handled by actions/could be handled by aria-actions 18:02:25 s/when actions come/when aria-actions come 18:03:14 s/one of my concerns is that I've seen devs getting around ARIA convention. Need to look at accname spec and other things/I've seen devs use ARIA to get around HTML prohibition on nested interactives. Which results in unexpected output (HTML serializes, not nests). So I fear accName would need an update 18:03:40 s/e.g., focus/browser mode/e.g., focus/browse mode 18:04:29 s/don't worry about unsupported cases/don't worry about unsupportable cases 18:04:43 s/Scott said most of what I wanted to do/Scott said most of what I wanted to say 18:07:35 s/Wilco that we're not doing you're idea/Wilco that we're not doing your idea 18:07:52 s/for ARIA #2037, is still in draft status/for ARIA PR #2037, is still in draft status 18:08:14 s/this issue was a related PR and re-used as much work as we did/this issue was a related PR and re-used as much work as we could 18:08:29 s/managing focus on toolbars /managing focus in toolbars 18:08:55 s/any objections to merging this right now?/yes; any objections to merging this right now? 18:10:04 rrsagent, make minutes 18:10:05 I have made the request to generate https://www.w3.org/2025/04/24-aria-minutes.html Rahim 18:11:24 s/depends on mode of navigation, browser mode/e.g., focus/browse mode/browser mode/depends on mode of navigation, such as focus or browse mode 18:11:36 rrsagent, make minutes 18:11:37 I have made the request to generate https://www.w3.org/2025/04/24-aria-minutes.html Rahim 18:12:29 s/(e.g., focus/browse mode/browser mode/depends on mode of navigation, such as focus or browse mode/e.g., focus/browse mode/browser mode)/depends on mode of navigation, such as focus or browse mode 18:12:35 rrsagent, make minutes 18:12:37 I have made the request to generate https://www.w3.org/2025/04/24-aria-minutes.html Rahim 18:13:10 ChrisCuellar has joined #aria 19:59:50 ChrisCuellar has joined #aria 21:19:10 Adam_Page has joined #aria 22:25:19 ChrisCuellar has joined #aria