16:38:11 RRSAgent has joined #aria 16:38:15 logging to https://www.w3.org/2025/01/23-aria-irc 16:38:15 RRSAgent, make logs Public 16:38:16 Meeting: ARIA WG 16:40:38 chair: JamesNurthen 16:40:43 agendabot, find agenda 16:40:43 jamesn, OK. This may take a minute... 16:41:03 Sorry, I did not find an agenda. 16:42:35 agendabot, find agenda 16:42:35 jamesn, OK. This may take a minute... 16:42:52 Sorry, I did not find an agenda. 16:44:12 agenda: https://lists.w3.org/Archives/Public/public-aria/2025Jan/0011.html 16:44:12 clear agenda 16:44:12 agenda+ [New Issue Triage](https://tinyurl.com/f6fhu4bv) 16:44:12 agenda+ [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-01-16+repo%3Aw3c%2Faria&type=Issues) 16:44:12 agenda+ [WPT Open PRs](https://bit.ly/wpt_a11y) 16:44:13 agenda+ [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) 16:44:16 agenda+ [\[AriaNotify\] Naming for the priority property](https://github.com/w3c/aria/issues/2333) 16:44:19 agenda+ [Consider ariaNotify being named a more general accessibility notification in HTML/DOM rather than an ARIA-specific mixin in the ARIA spec](https://github.com/w3c/aria/issues/2399) 16:44:22 agenda+ [Tentative: update point E. Host Language Label of the Acc Name algorithm](https://github.com/w3c/aria/pull/2405) 16:44:26 agenda+ [Should the 'row' role really be necessary for parents of 'gridcell' and other cell role elements?](https://github.com/w3c/aria/issues/2402) 16:44:29 agenda+ [\[accname\] Explicitly state UAs must ignore “aria-label” for slots](https://github.com/w3c/aria/pull/2385) 16:44:32 agenda+ [Accessible Rich Internet Applications Working Group](https://www.w3.org/groups/wg/aria/) ([View Calendar](https://www.w3.org/groups/wg/aria/calendar/)) 17:00:56 Adam_Page has joined #aria 17:57:31 filippo-zorzi has joined #aria 18:00:19 melsumner has joined #aria 18:01:54 alisonmaher has joined #aria 18:02:13 present+ 18:02:16 Brett-Lewis has joined #aria 18:02:28 present+ 18:02:32 giacomo-petri1 has joined #aria 18:02:41 present+ 18:02:44 aardrian has joined #aria 18:02:50 present+ 18:02:54 present+ 18:02:57 present+ 18:02:58 katez has joined #aria 18:02:59 scribe: Rahim 18:03:08 scott has joined #aria 18:03:22 present+ 18:03:23 present+ 18:03:28 zakim, next item 18:03:28 agendum 1 -- [New Issue Triage](https://tinyurl.com/f6fhu4bv) -- taken up [from agendabot] 18:03:35 present+ 18:03:58 aaronlev has joined #aria 18:04:20 zakim, close this item 18:04:20 agendum 1 closed 18:04:21 I see 9 items remaining on the agenda; the next one is 18:04:21 2. [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-01-16+repo%3Aw3c%2Faria&type=Issues) [from agendabot] 18:04:23 zakim, next item 18:04:23 agendum 2 -- [New PR Triage](https://github.com/search?l=&q=is%3Aopen+is%3Apr+created%3A%3E%3D2025-01-16+repo%3Aw3c%2Faria&type=Issues) -- taken up [from agendabot] 18:04:27 present+ 18:04:39 zakim, close this item 18:04:39 agendum 2 closed 18:04:40 I see 8 items remaining on the agenda; the next one is 18:04:40 3. [WPT Open PRs](https://bit.ly/wpt_a11y) [from agendabot] 18:04:43 zakim, next item 18:04:43 agendum 3 -- [WPT Open PRs](https://bit.ly/wpt_a11y) -- taken up [from agendabot] 18:05:28 jcraig: Giacomo, are you ready for me to merge the ones that are ready? 18:05:30 Francis_Storr has joined #aria 18:05:33 present+ 18:05:44 Siri has joined #aria 18:05:49 giacomo-petri1: one is not complete and requires further discussion 18:05:56 present+ 18:06:11 jcraig: I'll do that (merge the ones that are ready) 18:06:20 StefanS has joined #aria 18:06:36 present+ 18:07:14 scott: The "figure-name-no-figcaption" (WPT #49647) needs review 18:07:17 zakim, next item 18:07:17 agendum 4 -- [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from agendabot] 18:08:48 jcraig: no deepdives currently scheduled; what about the whitespace deepdive? 18:09:10 melsumner: the whitespace deepdive is waiting to be scheduled 18:09:26 zakim, next item 18:09:26 agendum 5 -- [\[AriaNotify\] Naming for the priority property](https://github.com/w3c/aria/issues/2333) -- taken up [from agendabot] 18:09:35 sarah has joined #aria 18:09:56 present+ 18:10:27 q? 18:10:33 alisonmaher: we discussed this one; some of the naming for the property is being discussed, e.g., using "high" or "low". I like the idea of "normal" and seen it used in other APIs such as grid. Curious what others think before we finalize those names 18:10:38 jcraig: sounds good to me 18:10:56 jamesn: does anyone object to "high" and "normal"? 18:11:40 scott: could there be confusion around what "normal" means (not an objection) 18:12:27 jamesn: similar concerns have come up around the "disabled" property 18:13:08 jamesn: if we're anticipating disagreement, could we use "default"? 18:14:17 jcraig: these are technical terms for "non-human constructs"; can have that discussion when it comes up. Visual descriptions such as "did you see the movie" are not usually problematic 18:15:03 FWIW I think I'm saying, have a prepped statement and respond with it, I don't think it's productive to engage in those kinds of conversations in this context. 18:15:35 jamesn: consensus has been reached on "high" and "normal" (see ARIA #2333) 18:15:47 zakim, next item 18:15:47 agendum 6 -- [Consider ariaNotify being named a more general accessibility notification in HTML/DOM rather than an ARIA-specific mixin in the ARIA 18:15:49 ... spec](https://github.com/w3c/aria/issues/2399) -- taken up [from agendabot] 18:16:45 Matt_King has joined #aria 18:17:20 q+ 18:17:29 alisonmaher: James C. brought up several topics; one is the naming for ariaNotify that was discussed in an issue linked by Clay. I'm open to renaming it (e.g., ATNotify may be unclear whereas ariaNotify is easier to type). The other open question is where this should live; currently in the ARIA spec but maybe this should live in the HMTL spec 18:18:07 jcraig: I get the spelling point; why wouldn't accessibilityNotify be as clear as ariaNotify? 18:18:24 q+ 18:18:31 ack jcraig 18:19:05 ...I agree that ATNotify would be ambiguous. Part of the reason I mentioned it (not ariaNotify) is that you can use it for a number of things that don't leverage ARIA, or use it in another host language, or another HTML feature. Number of scenarios that aren't ARIA specific 18:19:08 ack me 18:19:17 ChrisCuellar has joined #aria 18:19:31 keithamus has joined #aria 18:19:35 q+ 18:19:45 acj aaronlev 18:19:46 jamesn: I voice support for accessibilityNotify rather than ariaNotify. ARIA is used for many things, and it would be nice if it was reserved only for ARIA 18:19:50 ack aaronlev 18:19:59 q+ 18:20:19 aaronlev: I agree with ariaNotify; people thinking about accessibility will link it to ARIA and then look that up. It's a branding thing 18:20:38 q+ 18:20:44 ack smockle 18:20:48 ...I think this is closer to what ARIA does, which does something specifically for assistive technologies 18:21:06 ack keithamus 18:21:14 Clay: ARIA calls out accessible rich [internet] applications; is it valuable to call out ARIA?  18:21:42 keithamus: ariaNotify exists in lieu of the higher level tools that we have yet found a way to express in HTML and CSS 18:21:59 jamesn: I don't have a strong opinion either way; happy to go with ariaNotify if that's the consensus 18:22:38 jcraig: Clay asked if it could just be "notify"; it may not be clear enough and people may think it's not for accessibility purposes. My feeling is still that accessibilityNotify is better 18:22:39 since ARIA is already a synonyme for screen reader support and acc is broader, vote is for ARIA 18:22:39 atNotify? 18:23:00 jamesn: how should we achieve consensus? People don't seem to have strong opinions. Does anyone object to sticking with ariaNotify? 18:23:00 s/Clay asked/Kate asked/ 18:23:27 q+ 18:23:52 Matt_King: ARIA here is a stand in for filling in a gap for assistive technologies. ARIA is more equal to AT than accessibility, so I'm kind of leaning towards ariaNotify since ARIA is a good stand in for AT 18:24:51 q? 18:24:55 ack jcraig 18:25:05 jcraig: I would agree that aria is the appropriate name, if it was a stand in for a temporary gap that we could solve for later. Every non-web platform has capabilities unavailable in web (e.g., custom views, notifications) and ariaLive is kind of like that 18:25:43 Matt_King: I understand the native applications of this; e.g., AX has become shorthand for accessibility but more AT-focused. Would that be better? 18:25:47 q+ 18:26:07 q+ to mention non AT uses 18:26:07 ...my question is, instead of accessibilityNotify, how about AXNotify? 18:26:14 qq+ 18:26:21 Q+ 18:26:24 keithamus has joined #aria 18:26:30 q? 18:26:32 ...it's shorter and AX is also more often associated with accessible experience, which is more associated with AT rather than generic accessibility 18:26:38 sarah has joined #aria 18:26:39 ack jcraig 18:26:39 jcraig, you wanted to react to jcraig 18:26:45 +1 to referencing prior art if possible 18:26:49 q- jcraig 18:27:10 "AX" is something I associate with the Apple accessibility API specifically at this point 18:27:49 q- 18:28:04 jcraig: (continuing previous comment) I can think of scenarios where this goes more broadly to just the specific AT case. Even in the AT scenarios, this could be rendered to braille, speech, on-screen; we could use this (API) to render a badge on screen. There may be some scenarios, such as speech UIs, maybe there's this other notification that could be triggered in other contexts outside of AT so I still think accessibility is a better fit 18:28:04 (accessibilityNotify) 18:28:08 ack me q? 18:28:15 q? 18:28:24 qv? 18:28:39 StefanS: I've seen ARIA prefixed on other APIs and this term is established indicating AT/accessibility support. Maybe something else could be better 18:28:42 ack aardrian 18:29:06 q+ 18:29:07 aardrian: I'm fine with the other suggestions, except AX. Some people think that it relates to a particular product (e.g., Deque axe) 18:29:21 ack Brett-Lewis 18:29:41 q+ 18:29:52 ack keithamus 18:29:55 Brett-Lewis: I wanted to vote for ariaNotify. I think ARIA is identified with making something accessible, and I think ariaNotify would be the most discoverable choice. It's become more synonymous with accessibility, maybe even more than accessibility 18:30:20 keithamus: if we could all agree that ariaNotify is the least worst of the options, that would be good for a standards discussion 18:30:26 jamesn: any objections to ariaNotify? 18:30:47 ...the consensus is that we will go with ariaNotify (nobody objects) 18:31:02 q+ 18:31:11 ack keithamus 18:31:45 keithamus: it certainly wouldn't be the HTML spec. It could live in the DOM spec but it would be confusing because there's no existing precedent for the kind of mappings that require ariaNotify to function (only ARIA and related spec which feel like the best place) 18:32:21 jcraig: because it's being named ARIA, it should be left in the ARIA spec. There are some scenarios in CSS where it mentions accessibility expectations (but not mappings) 18:32:38 q 18:32:41 q+ 18:32:41 jamesn: It can live in ARIA, but the DOM spec should reference it 18:33:09 ack me 18:33:14 keithamus: not necessarily, it can live entirely in the ARIA spec. Unlike ElementInternals, it's explicit in the ARIA spec already 18:33:56 jamesn: if someone is implementing the DOM spec in the browser, they should be aware that they need to do this (ariaNotify) as well 18:34:16 q+ 18:34:24 ack dmontalvo 18:34:42 jcraig: nice thing about putting it in DOM/HTML/ECMA is that you'd get other non-accessibility reviewers and good questions can come out of that 18:35:11 dmontalvo: should it be in the main spec, or in a separate module. Will see how we go about doing that 18:35:39 jcraig: don't have a strong opinion but we could break out this mixin (interface), such as how the accname spec was broken out because of it's complexity 18:36:01 jamesn: not that we're using a monorepo, it's easier to make changes to ARIA-related specs 18:36:27 zakim, next item 18:36:27 agendum 7 -- [Tentative: update point E. Host Language Label of the Acc Name algorithm](https://github.com/w3c/aria/pull/2405) -- taken up [from agendabot] 18:37:10 jamesn: agenda+ was added for this last week 18:38:04 q+ 18:38:10 Bryan: seems to be there was confusion, different understandings as to what presentational elements do. My understanding is that presentational = nullified in the a11y tree and no longer exists. If this is the case, and an element that doesn't exist has a name, not sure what the impact is 18:39:41 scott: I was part of this discussion; my read is that making as presentational (role=presentation) is that role semantics are removed but does not move that other accessibility/HTML semantics are removed. Because it's marked as presentational, don't believe that everything about it (semantics) goes away 18:40:40 Bryan: if I take a tabbed interface, e.g., tablist, and have intervening elements between those roles, they disappear in the a11y tree. If it's not disappearing, what would that be? 18:42:04 aaronlev: the reason that `