17:00:03 RRSAgent has joined #aria 17:00:07 logging to https://www.w3.org/2025/10/09-aria-irc 17:00:07 agendabot, find agenda 17:00:07 spectranaut_, OK. This may take a minute... 17:00:07 agenda: https://www.w3.org/events/meetings/5a155237-d896-464b-9c5f-6dd1654293ae/20251009T130000/ 17:00:07 clear agenda 17:00:07 agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2025-10-02+repo:w3c/aria&type=Issues 17:00:07 agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y 17:00:07 RRSAgent, make logs Public 17:00:08 Meeting: ARIA WG 17:00:08 agenda+ -> TPAC planning https://tinyurl.com/ariaf2fcandidate 17:00:08 chair: ValerieYoung 17:00:09 agenda+ -> CSS: handing the a11y of anchor positioning https://github.com/w3c/html-aam/issues/545 17:00:12 agenda+ -> Should ARIA boolean-like attributes behave like HTML boolean attributes? https://github.com/w3c/aria/issues/2639 17:00:15 agenda+ -> ARIA IDL updates: enumerated attribute conversions, new "enumerated" wai-aria type, IDL examples https://github.com/w3c/aria/pull/2484 17:00:23 Francis_Storr has joined #aria 17:00:49 giacomo-petri has joined #aria 17:00:57 present+ 17:01:03 Adam_Page has joined #aria 17:01:43 Stefan has joined #aria 17:01:55 present+ 17:01:57 present+ 17:02:14 elguerrero has joined #aria 17:02:21 present+ 17:03:01 katez has joined #aria 17:03:12 scribe: hdv 17:03:12 present+ 17:03:18 present+ 17:03:30 Zakim, take up next 17:03:30 agendum 1 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2025-10-02+repo:w3c/aria&type=Issues -- taken up [from agendabot] 17:03:34 present+ 17:03:38 present+ 17:03:40 present+ 17:04:05 present+ 17:04:09 chrishtr: is it all open PR we're looking at or a filter? 17:04:15 spectranaut_: all PRs on ARIA 17:04:28 spectranaut_: created in the last week 17:04:32 https://github.com/w3c/aria/pull/2577 17:04:48 chrishtr: I was wondering about #2577, is there a process in this meeting to make progress on that? 17:05:08 spectranaut_: if you want to discuss is at the next, you can always `agenda+` it 17:05:11 present+ 17:05:18 https://github.com/w3c/aria/pull/2577 17:05:21 spectranaut_: we can look at it right now 17:05:29 chrishtr: I'd like to understand if there's anything blocking landing it? 17:05:38 spectranaut_: we don't land until there are 2 implementations 17:05:55 jcraig: I thought there was a scenario with one implementation and support from another, or some variant of that? 17:06:02 spectranaut_: let's check our documentation 17:06:14 present+ 17:06:32 chrishtr: this one has a positive decision from Gecko and Webkit 17:06:41 present+ 17:07:04 spectranaut_: the reason we're hesitant to land it is that we'd have to pull it from the spec when we want to release if there's no implementation, which is extra work 17:07:10 Jacques has joined #aria 17:07:40 spectranaut_: so ideally we'd like to be more clear on whether they actually plan to have it somewhere in the near future 17:08:00 sarah has joined #aria 17:08:03 chrishtr: would a comment from them suffice? 17:08:09 spectranaut_: yes that'd help 17:08:23 Jacques: this would need platform APIs probably 17:08:30 keithamus: yes you're right on that 17:08:48 spectranaut_: yes it's just a platform API 17:08:56 chrishtr: is testing in WPT a requirement for new things? 17:09:11 spectranaut_: we'd like it but it's not blocking 17:09:51 keithamus: I can't make a firm commitment at this point but will say GitHub sponsored this a while ago and if one of them would be interested in landing it I would be happy to coach them through it 17:10:13 chrishtr: for purpose of landing this, that's probably not firm enough? 17:10:21 spectranaut_: exactly 17:10:38 jcraig: I'll give you another not firm enough statement… we certainly intend to at some point but don't have a timeline at this point 17:10:50 https://github.com/w3c/aria/pull/2650 17:10:52 spectranaut_: ok, let's talk about the next PR… from jcraig 17:11:00 jcraig: it's 6 years in the making 17:11:24 jcraig: we had full review across the board 17:11:38 jcraig: and not quite good enough support from Chromium 17:12:08 jcraig: this has been a long time coming and I would love to see it merged during or before TPAC 17:12:33 q+ 17:12:50 jcraig: reason there is a new PR is that previous ones were before Prettier and other tooling so wasn't worth redoing. So it's the same content but a fresh PR 17:13:17 q+ 17:13:20 jcraig: keithamus specificially would be nice to have review this as we haven't had a Mozilla review for it yet, we did have a Google review before 17:13:25 keithamus: I'll happily review it 17:13:55 ack chrishtr 17:14:01 chrishtr: jcraig, who reviewed from Google? 17:14:15 jcraig: Aaron Leventhal and Brian @@@ and I think Valerie 17:14:29 chrishtr: is implementation (in WebKit) straightforward? 17:14:37 siri has joined #aria 17:14:46 Rahim: relatively easy aside from finding descendant nodes matching the criteria; but yeah pretty easy 17:15:05 Rahim: didn't have to implement anything new, methods I used were already available 17:15:13 q? 17:15:34 jcraig: we thought it'd help with @@@ search, but authors didn't like it so we switched to depth first search… should be easy enough either way 17:15:40 ack Rahim 17:15:40 chrishtr: will check with people from Blink so we can unblock this 17:15:42 WebKit PR for nameFrom: heading: https://github.com/WebKit/WebKit/pull/43080 17:16:03 present+ 17:16:11 Rahim: quick question for jcraig on the PR… (2650) 17:16:33 Rahim: re roles affected: I wasn't aware form and region get name from heading? 17:16:56 jcraig: great question, could you put it in the PR? that was from the previous patch, hadn't looked back to check why we had it for form and region 17:17:03 q+ matt 17:17:29 ack matt 17:17:51 matt: I thought we left region out of this… because it requires a name and if you don't explicitly add a name the region the AT will ignore it? 17:18:13 jcraig: yes… but this PR and previous PR had changed that. Will take that as a note, this is why I rerequested review 17:18:38 matt: that change to name from region happened at a point that may have been before the last review? 17:18:46 matt: and we also changed dialog during that time?\ 17:18:55 matt: could become a tricky validation role? 17:18:59 s/role/rule 17:19:09 jcraig: I'll take these notes 17:19:21 matt: we'll need to think about how it affects validation and authoring rules and normative statements 17:19:34 jcraig: if you want to review this, matt, I'll add you 17:19:51 q+ 17:19:55 matt: simplest way to move it forward may be… that it doesn't affect region or form 17:20:07 jcraig: if that's the right solution it would be easiest, but if it's the wrong solution probably not? 17:20:35 ack siri 17:20:37 spectranaut_: any more comments on this PR? 17:21:09 siri: may be good to have names from headings, but if the author wants can they override this? 17:21:24 jcraig: this never overrides names from authors, aria-labelledby and aria-label would override 17:22:06 siri: in the next version of ARIA, having labels requirement changes, how does this work? 17:22:36 jcraig: previously for dialogs it explicitly said it must have a label now it says SHOULD 17:23:21 spectranaut_: then we have two more issues that are editorial, we don't need to talk about them 17:23:24 Zakim, take up next please 17:23:24 agendum 2 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot] 17:24:10 spectranaut_: there is a new PR from Mike… for web features 17:24:21 mike: I can have a look over this 17:24:34 Zakim, take up next please 17:24:34 agendum 3 -- -> TPAC planning https://tinyurl.com/ariaf2fcandidate -- taken up [from agendabot] 17:25:06 spectranaut_: just a reminder, we'll be planning to agenda soon, please add F2F candidate issue asap if you have them 17:25:38 Zakim, take up next please 17:25:38 agendum 4 -- -> CSS: handing the a11y of anchor positioning https://github.com/w3c/html-aam/issues/545 -- taken up [from agendabot] 17:26:08 Daniel: Peter sent regrets 17:26:24 spectranaut_: Peter wrote in the issue we have two implementations for anchor positioning 17:26:35 spectranaut_: should we wait for Peter for this one? 17:26:42 Matt_King has joined #aria 17:26:53 present+ 17:27:00 spectranaut_: let's discuss in another week 17:27:02 present+ 17:27:03 present+ 17:27:20 chrishtr: if next week I can make sure Chrome folks are present 17:27:21 Zakim, take up next 17:27:21 agendum 5 -- -> Should ARIA boolean-like attributes behave like HTML boolean attributes? https://github.com/w3c/aria/issues/2639 -- taken up [from agendabot] 17:28:09 Rahim: James raised a good question re how ARIA attributes are different from HTML attributes 17:28:31 s/ARIA attributes/ARIA IDL attributes 17:28:36 s/HTML attributes/HTML IDL attributes 17:28:52 Rahim: if you use `aria-required` with empty string, it results in false 17:29:03 q+ 17:29:06 Rahim: should boolean-like ARIA attribute behave like HTML boolean attributes? 17:30:16 jcraig: some will equate to false, some are true/false/undefined, where undefined is a separate value than false and it means something different which implementation figures out 17:30:36 jcraig: it's based on element or some other determinable aspect of the DOM 17:30:39 q+ 17:30:42 jcraig: there's a lot of overlap that's possible 17:30:53 ack keithamus 17:31:09 keithamus: there are a couple of attributes in HTML that behave the same as these, that have enumerated keywords of true and false 17:31:17 keithamus: like spellcheck, writing suggestions and draggable 17:31:46 keithamus: all three, I think, reflect the content attribute and resovle to true or false but that's not reflected to the IDL 17:31:54 keithamus: i don't think it's particularly alien for these properties to do what they do 17:32:00 q- 17:32:03 q+ 17:32:27 keithamus: this has a higher degree of web compat risk and potentially paints us into a corner, would have a stronger objections to this than I did to the prior work for enumerated attributes 17:32:35 Rahim: I figured as much, thanks James and keithamus 17:32:59 Rahim: now that we've migrated a lot, might be worth looking at more of these attributes and ensure to align with best possible IDL types 17:33:05 q+ 17:33:06 ack front-endian-jane 17:33:34 front-endian-jane: this would also cause a number of problems on the author side of things, as there's so much documentation about this. On the author side we can see more confusion about how HTML does booleans than how ARIA does booleans 17:33:45 q+ 17:33:48 ack jcraig 17:33:53 front-endian-jane: not a 100% against this, but if we change this it could cause a lot of uproar among authors 17:34:19 jcraig: I also vote for the enumerated string values, also considering the extensibility argument that keithamus brought up 17:34:37 jcraig: because it's never been boolean, we can be sure there's no authors that are using this for comparison 17:34:49 jcraig: so there's near zero web compat risk 17:34:57 ack giacomo-petri 17:35:02 jcraig: and there's no web compat benefit to changing it to boolean as far as I can tell 17:35:48 spectranaut_: wanted to add to author confusion point that jcraig brought up… I see a lot of code with aria-disabled=true/false, eg aria-disabled=false. Can imagine changing this would cause a lot of problems with authors 17:35:54 s/spectranaut_/giacomo-petri 17:36:27 jcraig: to clarify, giacomo-petri… when the author set the value to false, what wouldn't work? 17:36:40 jcraig: wouldn't it still be an invalid value? 17:36:50 jcraig: that falls back to false? 17:37:25 front-endian-jane: I can't remember the exact details, but I've seen something similar to what giacomo-petri was saying 17:37:31 s/near zero web compat risk/less web compat risk for enum than boolean/ 17:37:35 q? 17:38:37 keithamus: I think the general thing to take away from this, enumeration with a string true or false is probably a bad idea, want to use aliases like on or off instead… if we had something like aria-checked=on or =checked, might have eleviated some of this 17:38:46 Zakim, take up next 17:38:46 agendum 6 -- -> ARIA IDL updates: enumerated attribute conversions, new "enumerated" wai-aria type, IDL examples https://github.com/w3c/aria/pull/2484 -- taken up [from agendabot] 17:39:20 Rahim: more IDL fun! 17:39:29 Rahim: got some good feedback from James and Anne 17:39:52 q+ 17:39:58 Rahim: first issue, aria-haspopup… I believe true and menu are synonyms… which is the canonical value, true or menu? and how should ARIA reflection works when this is provided? 17:40:00 ack keithamus 17:40:57 keithamus: I think we should define it such that it's not the string 'true'… I think there's already mechanics for the canonicalisation of keywords 17:41:18 keithamus: so if there was a string 'true' in the DOM it would be returned as 'menu' in the IDL still 17:41:25 q+ 17:41:26 keithamus: so just depends on which way we would canonicalise 17:41:59 ack me 17:42:01 Rahim: in IDL reflection, do we want 'true' or 'menu' to reflect as the same values, should they be synonyms? 17:42:31 jcraig: wanted to ask Matt_King… sorry if you're the wrong person… wasn't there a point we made 'true' the canonical value? 17:42:37 q+ 17:42:58 Matt_King: in 1.1… I'm not sure if it became an antipattern… what happened was the original values were only added to get some compromise in what we needed for just the combobox role 17:43:08 Matt_King: we kept true as a synonym to menu for compatibility 17:43:46 Matt_King: I kind of lean into keithamus's direction… based on how aria-haspopup has been used now… quite a few people argued for using the values of haspopup in other places than combobox, particularly buttons 17:44:06 Matt_King: not sure if there's consensus on that… can't see what the problem would be of making menu the canonical value 17:44:20 jamesn has joined #aria 17:44:51 spectranaut_: re Rahim's question just wanted to say re how ATs handle these values… aria-haspopup=true is handled as aria-haspopup=menu in accessibility APIs 17:44:58 spectranaut_: so menu is the defualt 17:44:59 https://w3c.github.io/core-aam/#ariaHaspopupTrue 17:45:18 s/defualt/default 17:45:32 Rahim: ok so 'menu' would be the canonical keyword with 'true' as a synonym 17:45:52 Rahim: someone asked me… why would aria-haspopup return null instead of false? 17:46:22 Matt_King: it's like aria-pressed… if you have a button where it's not set it's null but if there is one it's false 17:47:22 jcraig: may be different if there's a native control that uses aria-haspopup where we'd use undefined as the missing or invalid value 17:47:24 ack spectranaut_ 17:48:12 Rahim: ok so aria-haspopup will return undefined state which is null 17:48:24 Rahim: false and empty string return false I believe 17:48:53 Matt_King: this could be one of the places where we want 'false ' to return 'undefined' because we had 'true' return 'menu'… enumerated things that initially, in ARIA 1.0 was a boolean 17:49:01 Matt_King: maybe we should go away from false entirely here 17:49:08 jcraig: not sure if undefined is any better in that regard 17:49:45 Rahim: so sounds like 'false' remains a valid keyworrd? 17:49:52 jcraig: have to think about that some more 17:50:07 keithamus: would be open, but would probably raise similar conversations up until this point, especially regarding web compat 17:50:22 keithamus: if we start returning entirely new values, a lot of guidance may have to be updated 17:50:54 jcraig: hm maybe not worth doing in that case 17:51:18 Rahim: next question, how do I specify undefined in the attribute values table? 17:51:27 Rahim: please review that when you look at the PR 17:51:45 Rahim: there's some overlap between concepts of undefined state, and the "undefined" string value 17:52:19 Rahim: last time I took away it's okay to use an undefined state, but undefined string value is provided to the content attribute it would be for a missing value default 17:52:28 Rahim: folks that are interested, please take a look at that section 17:53:45 Rahim: when MDN talks about content attributes, they list undefined as an actual value, which I think wasn't the intention, it was for the absence of the value to be undefined 17:54:57 Rahim: another question, last time we talked about this there seemed to be consensus to add an undefined state. My question is should all ARIA attributes that support null be specified as an undefined state? 17:56:50 Rahim: there's an explainer linked from the PR description, it has a table for all the updated attributes, 17:56:57 Rahim: should everything that has `null` be undefined state? 17:57:05 jcraig: I think that's probably editorial errata in the past? 17:57:29 keithamus: I think I mentioned a while ago… I think we don't have to have the undefined state, if we don't mention it in prose 17:57:50 keithamus: there might be no point in labeling a state… labeling them the undefined state might make it more confusing 17:58:08 jcraig: i recall you suggested 'no state' 17:58:24 q+ 17:58:54 jcraig: I recall because we had the string value of undefined that had previously been there, we wanted the reflection to match that 17:59:01 jcraig: even if the string value you assigned could map to something else 17:59:14 jcraig: but not sure if there's a benefit to keeping that in this scenario 17:59:42 jcraig: re Rahim's question , to my recollection everything we call null also means undefined 18:00:09 Rahim: re undefined state discussion, Anne chimed in and discouraged us from going with no state 18:00:23 Rahim: he recommended we name that state 18:00:33 Rahim: will follow up with him and perhaps keithamus and jcraig 18:01:41 s/I recall because we had the previously assignable string value of "undefined" that had previously been there, we wanted the reflection to match that/I recall because we had the string value of undefined that had previously been there, we wanted the reflection to match that conceptually, hence the named Undefined State/ 18:02:37 s/but not sure if there's a benefit to keeping that in this scenario/but not sure if there's a benefit to keeping that in this scenario over the NoState suggestion (Update: There is not. Either fine with me.)/ 18:23:29 zakim, make minutes 18:23:29 I don't understand 'make minutes', spectranaut_ 18:23:36 zakim, end meeting 18:23:36 As of this point the attendees have been hdv, front-endian-jane, Stefan, Adam_Page, katez, chrishtr, filippo-zorzi, jcraig, elguerrero, Francis_Storr, Rahim, Daniel, giacomo-petri, 18:23:39 ... siri, Matt_King, sarah, Jacques 18:23:39 RRSAgent, please draft minutes v2 18:23:40 I have made the request to generate https://www.w3.org/2025/10/09-aria-minutes.html Zakim 18:23:47 I am happy to have been of service, spectranaut_; please remember to excuse RRSAgent. Goodbye 18:23:47 Zakim has left #aria