16:59:29 RRSAgent has joined #aria 16:59:33 logging to https://www.w3.org/2024/04/18-aria-irc 16:59:33 RRSAgent, make logs Public 16:59:34 Meeting: ARIA WG 16:59:35 Francis_Storr has joined #aria 16:59:38 chair: ValerieYoung 16:59:42 agendabot, find agenda 16:59:42 spectranaut_, OK. This may take a minute... 16:59:46 rschwartz has joined #ARIA 17:00:08 Sorry, I did not find an agenda. 17:01:20 aardrian has joined #aria 17:01:22 pkra has joined #aria 17:01:28 scotto has joined #aria 17:01:29 present+ 17:01:41 present+ 17:01:43 present+ 17:01:45 present+ 17:01:52 agendabot, find agenda 17:01:52 spectranaut_, OK. This may take a minute... 17:01:52 agenda: https://www.w3.org/events/meetings/2b57854a-65cb-421e-b9e0-f9a8da31f160/20240418T130000/ 17:01:52 clear agenda 17:01:52 agenda+ -> New Issue Triage https://bit.ly/3TYsw65 17:01:53 agenda+ -> New PR Triage https://bit.ly/3Q7mI9s 17:01:55 agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y 17:01:58 agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates 17:02:00 agenda+ -> TPAC 2024 https://www.w3.org/events/tpac/2024/ 17:02:03 agenda+ -> Deprecation of aria-invalid as a Global property and proposed Introduction of aria-MarkedType/aria-markType https://github.com/w3c/aria/issues/2155 & -> Issue: CSS Highlights Not Clearly Documented in AAM https://github.com/w3c/core-aam/issues/226 17:02:07 agenda+ -> Clarification of when live regions are meant to be announced by AT https://github.com/w3c/aria/issues/2154 , -> Clarification of when a role="alert" should be announced by AT / fire an alert event https://github.com/w3c/core-aam/issues/225 , -> Clarification of when a role="alert" should 17:02:12 … be announced by AT / fire an alert event https://github.com/w3c/aria/issues/2153 17:02:15 agenda+ -> Question: time can have a name from author? https://github.com/w3c/aria/issues/2075 17:02:18 agenda+ -> Add nameFrom: heading steps to computation after spec addition ARIA PR #1860 is reviewed. https://github.com/w3c/accname/issues/182 17:02:22 agenda+ -> Trim whitespace from computed accessible name/description https://github.com/w3c/accname/issues/95 17:02:26 scribe: Adam_Page 17:02:30 present+ 17:02:32 zakim, next item 17:02:32 agendum 1 -- -> New Issue Triage https://bit.ly/3TYsw65 -- taken up [from agendabot] 17:02:35 present+ 17:02:45 giacomo-petri has joined #aria 17:02:48 present+ 17:03:26 spectranaut_: aria#2162 17:03:26 sarah has joined #aria 17:04:04 giacomo-petri: many websites with complex dashboards, multiple tabs — when interacting with a single card, only that card’s content is affected 17:04:20 ... wondering if it makes sense to enable users to recognize these kinds of widgets 17:04:25 melsumner has joined #aria 17:04:25 present+ Daniel 17:04:32 jamesn has joined #aria 17:04:47 spectranaut_: MarioBatusic proposed something related to this: aria#1944 17:05:03 ... please review, and then put agenda label on it for follow-up 17:05:03 present+ 17:05:23 spectranaut_: aria#2161 17:05:24 present+ 17:05:32 present+ 17:05:45 ... directory deprecation should be normative 17:05:50 CurtBellew has joined #aria 17:06:25 scotto: some editorial work could be done here 17:06:50 spectranaut_: let’s ask Jocelyn if she’d like to make this change 17:06:56 ... unless someone else wants it ;-) 17:07:24 spectranaut_: core-aam#227 17:07:32 ... do we mark things as deprecated in aam? 17:07:40 ... we keep mappings if they exist, right? 17:08:20 @scotto: yes. I don’t disagree with this. We can just add a “deprecated” note to the existing mapping to be clear 17:08:36 s/@scotto/scotto/ 17:08:48 spectranaut_: aria#2160 17:09:04 ... listitem should include `nameFrom: contents`, right? 17:09:24 cookiecrook: tests assume this, but spec doesn‘t actually state it 17:09:42 ... we could either make it name prohibited, or change it to allowed from author and content 17:09:55 ... there may be more elements, but listitem was the first that came up 17:10:11 ... the downside for name prohibited is that there could be some scenarios where we want to allow authors to name 17:10:17 ... even if uncommon 17:10:27 ... there’s an odd distinction in the spec 17:10:59 ... what’s the distinction between a heading’s computed label and a heading‘s concatenated _contents_? 17:11:08 ... might be worth agenda'ing 17:11:11 spectranaut_: yes 17:11:20 ... adding for future 17:11:29 spectranaut_: aria#2158 17:11:37 ... allow posinset/setsize for toolbars 17:12:06 ... follow-up from discussion about mechanism to relate controls without explicit grouping 17:12:20 scotto: yep, we can talk about it more, or we can just get to work 17:12:53 spectranaut_: yes, I believe there was consensus already 17:13:14 sarah: implicit indexing could be difficult/impossible 17:14:00 ... browser people will be needed for the implicit indexing part 17:14:09 aardrian: I think this makes sense 17:14:42 ... I’ll take assignment of this 17:15:02 present+ 17:15:39 aardrian:will this have any relationship to the core-aam spec? 17:15:48 spectranaut_: probably not, but reach out for help 17:15:59 scotto: I’m available too 17:16:21 spectranaut_: aria#2157 17:16:30 ... sounds editorial 17:16:48 pkra: I looked into this and think it’s not exported 17:16:59 spectranaut_: let’s leave as is then, hopefully annek will come through 17:17:05 spectranaut_: aria#2156 17:17:13 small correction on the minuting -- I wasn't being negative on the aria-posinset + toolbar thing, just wanted to suggest splitting the issue into the easy part (allowing the attrs on the roles), and the hard part (potential implicit index calculations for toolbar items) 17:17:35 ... this sounds like a straightforward editorial change 17:18:27 ... will see if Rahim would like to draft a PR 17:19:26 cookiecrook: I’ll also sync up with Rahim about this to clarify use of undefined 17:20:14 spectranaut_: html-aam#543 17:20:25 scotto: this is similar to the listitem one 17:21:02 related issue: https://github.com/w3c/aria/issues/2160 17:21:06 ... aria#2160 17:21:46 spectranaut_: html-aam#541 17:21:53 ... clarify contextual roles and accessibility parents 17:22:01 scotto: yes, I already started work on this 17:22:22 ... this is a follow-on to another issue related to li role mapping 17:23:07 ... this example is interesting because the parser actually error corrects 17:23:15 spectranaut_: okay, we’ll leave this one with you 17:23:24 spectranaut_: mathml-aam#33 17:23:26 ... already discussed 17:23:29 zakim, next item 17:23:29 agendum 2 -- -> New PR Triage https://bit.ly/3Q7mI9s -- taken up [from agendabot] 17:23:43 spectranaut_: html-aam#544 17:23:52 ... scotto already reviewed 17:24:50 spectranaut_: aria#2163 17:24:56 pkra: no need for another review 17:25:00 spectranaut_: let’s merge both 17:25:23 spectranaut_: aria#2159 17:25:33 ... note to expand radiogroup content 'allowances' 17:25:53 scotto: should there be a way to allow association elements outside of grouping them 17:26:07 ... e.g., in HTML, you can put radio buttons wherever you want and relate them with the `name` attr 17:26:20 ... but ARIA isn’t permissive in the same way 17:27:17 ... so this PR gives more freedom to authors 17:27:32 cookiecrook: I’ll review 17:27:52 ... we can already have an ARIA radio group that points to disparate radio buttons 17:28:08 ... it’s kjnd of a junk element, but comparable to host language radio group 17:28:54 scotto: the issue I see with that is with aria-owns, the a11y tree will reflect the element structure/adjacency differently than the DOM 17:29:04 s/kjnd/kind/ 17:29:10 sarah: I’ll review this too 17:29:18 spectranaut_: html-aam#540 17:29:29 ... clarify li role mapping 17:29:56 scotto: if an li element is used in some arbitrary location, then it should resolve to `generic` 17:30:17 ... and if a `generic` intervenes between it and a `list`, then it should still legitimately be a `listitem` 17:30:26 cookiecrook: this aligns with bullet rendering in most browsers too 17:30:30 ... I’ll also review 17:30:34 spectranaut_: anyone else? 17:30:43 sarah: I’ll review this too 17:30:49 zakim, next item 17:30:49 agendum 3 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot] 17:31:15 cookiecrook: I reviewed all these yesteday 17:31:40 ... for scott and Adam_Page, if you’ve committed changes based on my feedback, please request re-review 17:32:36 s/scott/scotto/ 17:32:40 spectranaut_: zakim, next item 17:32:55 zakim, next item 17:32:55 agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 17:33:22 spectranaut_: possible topic: should form fields in cells have names from table headers 17:33:29 aardrian: yes, I want to do this but haven’t begun 17:33:41 spectranaut_: please ping when you’re ready 17:34:25 aardrian: should I file the deep dive prep as a new issue? 17:34:45 spectranaut_: nah, just add a comment to aria#2148 17:34:59 ... we should schedule the deep dive once we have the explainer 17:35:16 ... can revisit scheduling it in the weekly call next week 17:35:42 zakim, next item 17:35:42 agendum 5 -- -> TPAC 2024 https://www.w3.org/events/tpac/2024/ -- taken up [from agendabot] 17:35:49 spectranaut_: TPAC is starting to get planned 17:36:13 Considering attending, but cannot commit yet. 17:36:15 ... it’s in the LA area at the end of September 17:36:19 I plan to attend. 17:36:45 I still have to figure it out but I'll make every effort to attend 17:36:46 bummed that I already know I can’t attend in-person, and possibly not even virtually — I’ve got a work conflict 17:37:04 Present+ 17:37:06 MattKing: I’ll be at TPAC 17:37:13 Planning to attend TPAC 17:37:14 Cynthia: 95% likely 17:37:18 present+ 17:37:20 likely to attend 17:37:21 Need to confirm, but I plan to attend 17:37:27 Planning to attend 17:37:35 Unlikely due to budgets. 17:37:35 spectranaut_: terrific, thanks 17:37:38 zakim, next item 17:37:38 agendum 6 -- -> Deprecation of aria-invalid as a Global property and proposed Introduction of aria-MarkedType/aria-markType https://github.com/w3c/aria/issues/2155 & -> Issue: CSS 17:37:41 ... Highlights Not Clearly Documented in AAM https://github.com/w3c/core-aam/issues/226 -- taken up [from agendabot] 17:37:52 spectranaut_: this is a two-issue topic 17:38:15 s/Cynthia/cyns/ 17:38:43 spectranaut_: aria#2155 — introduction of aria-MarkedType 17:39:05 DougGeoffey: I’ll ping Theo to see if he’s available to discuss 17:39:13 spectranaut_: next topic 17:39:18 ... 3 issues 17:39:31 ... live regions 17:39:39 zakim, next item 17:39:39 agendum 7 -- -> Clarification of when live regions are meant to be announced by AT https://github.com/w3c/aria/issues/2154 , -> Clarification of when a role="alert" should be 17:39:42 ... announced by AT / fire an alert event https://github.com/w3c/core-aam/issues/225 , -> Clarification of when a role="alert" should -- taken up [from agendabot] 17:40:04 spectranaut_: 3 issues with live regions 17:40:17 ... clarification for when live regions are meant to be announced 17:40:38 MattKing: being discussed right now 17:41:24 Adam_Page: about injection of live regions into DOM after load being already rendered on load 17:42:00 MattKing: this is not addressed by `atomic`? 17:42:06 cookiecrook: correct, it’s not 17:42:15 spectranaut_: well-researched issue explaining the lack of clarity 17:42:47 ... the first question is: what *is* our intention 17:43:04 cookiecrook: the implementations would like to settle on this 17:43:30 s/cookiecrook/jcraig/ 17:44:00 jcraig: let’s determine what implementations and AT+browser combos currently do, and then codify that 17:44:01 cyns has joined #aria 17:44:11 ... agree with Patrick that this is under-specified 17:44:20 ... and difficult to do automated testing 17:44:21 q+ 17:44:23 q+ 17:44:24 q+ 17:44:29 q? 17:44:41 q- 17:44:43 q+ 17:44:50 keithamus: interested in picking this up 17:44:51 ack keithamus 17:44:57 ... and testing for it as well 17:45:07 ... I volunteered to write spec for aria-notify 17:45:13 TheoHale has joined #ARIA 17:45:15 ... so there’s a strong intersection 17:45:20 present+ 17:45:28 jcraig: are you involved in interop meetings? 17:45:43 ... I’m gonna ask Simon Pieters to add you to that 17:46:02 spectranaut_: back to the queue 17:46:03 q? 17:46:09 ack sarah 17:46:40 sarah: is there any intent to change the core-aam mappings? 17:46:54 ... browsers are kind of following the spec if you interpret it just so 17:47:15 ... is part of the purpose to use the spec to *change* what browsers are doing? or just clarification? 17:47:30 spectranaut_: my reading is just clarification 17:47:39 keithamus: I agree, and we’ve discussed this 17:47:53 s/we’ve/Patrick and I have/ 17:48:10 keithamus: the point is to clarify this in the spec, and hopefully aria-notify will be the ultimate improvement 17:48:22 sarah: I’m skeptical that live regions will go away 17:49:02 spectranaut_: sarah, are you suggesting a change? 17:49:33 sarah: no, just wanting to point out that what we have now may not make a lot of sense but will also be fragile to change 17:49:54 ack scotto 17:50:32 scotto: I agree with jcraig that a lot of implementers are following this pattern, but they do that because of screaming from the a11y community via lots of testing to determine what works and recommend a technique 17:50:45 q+ 17:50:47 ... to sarah’s point, if we codify that, I do think that‘s a good thing, but role="alert" is the one odd duck out 17:51:05 ... role="alert" is actually better at announcing on page load, whereas other live regions are not nearly as good 17:51:09 ... so we can call that out in the spec 17:51:13 ... there was probably a reason 17:51:14 q+ 17:51:20 ... but that’s an important detail 17:51:43 jcraig: thanks for that clarification, I do recall that alert nuance 17:52:03 These are my tests from last year, if it's at all helpful: https://codepen.io/smhigley/pen/bGjJyyd 17:52:06 ... we should fix this, and we should create manual tests, and automated tests in chromium, gecko, webkit 17:52:13 ack jcraig 17:52:19 ... don’t want to get too far outside the scope of live regions until we have WPT coverage 17:52:29 ... but yes, it should be resolved and clarified 17:52:36 q+ mcking 17:52:40 ack m 17:53:06 1+ douggeoffray 17:53:12 MattKing: is it actually intended that role="alert" is somehow different from an equivalently coded live region that doesn’t have role="alert" on it? 17:53:17 q+ douggeoffray 17:53:24 ... because they don’t behave the same across today’s browsers 17:53:42 ... but that is not intentional, correct? 17:54:01 jcraig: there were enough ambiguities 10-12 years ago, it’s hard to say whether it was intentional 17:54:29 MattKing: alert was meant to be a shorthand synonym 17:54:46 ... but indicate to the OS that it could do something additional, like make a sound 17:55:11 ... if we’re just codifying behavior, I would want to resolve that ambiguity and ensure that we don’t *need* to use role="alert" to get the same SR response 17:55:20 jcraig: the difference is in the a11y APIs 17:55:32 ... and their pre-existing features 17:56:10 ... all other live regions do work the same, alert is the only exception 17:56:17 sarah: I would like to propose one specific change 17:56:30 Doug has joined #aria 17:56:55 ... keep the alert event for all APIs, but for role="status" add the wording to announce on insertion 17:57:23 ... and then to clarify for both only announce on insertion if it is *not empty* 17:57:43 ... to prevent breaking changes 17:58:24 MattKing: one thing from ARIA-AT, we are averse to treating alert differently — it has lost all its distinction 17:58:36 ... saying the word "alert", for example, is now being treated as a bug 17:59:20 q+ 17:59:22 ... there’s a lot of user blowback on this, especially for something like a chatbot, where the user hears "alert" way too often 17:59:38 q+ to ask sarah why status is different from log 17:59:41 ack me 17:59:53 spectranaut_: let’s discuss TheoHale’s issue next week 18:00:22 douggeoffray: I wanted to add, this just came up in Windows, NVDA/JAWS didn’t announce a live region when Narrator did 18:00:31 q+ to ask why Matt why we would not fire the engine event; JAWS could ignore it or change their UI if they so choose. 18:00:36 I think part of the benefit to spec'ing adding role=status as also announcing on insertion would be to (hopefully) cut down on authors using alerts for announcements that are not semantically alerts, but which they want to announce immediately when inserted 18:00:36 ... in Chromium today, we found out that UI implementation, it will fire on creation 18:00:41 ... and we filed a bug for that 18:00:49 q? 18:00:53 ... so that it will only announce on insertion and not creation 18:00:53 ack doug 18:01:12 jcraig: that sounds dangerous 18:01:27 douggeoffray: we were seeing inconsistent results in testing 18:01:42 s/insertion/text insertion/ 18:01:49 ss/that sounds dangerous/it sounds dangerous to make the change in one engine, where other engine have aligned on a different behavior/ 18:01:52 spectranaut_: think we need to keep discussing this 18:02:02 ack me 18:02:02 jcraig, you wanted to ask sarah why status is different from log and to ask why Matt why we would not fire the engine event; JAWS could ignore it or change their UI if they so 18:02:05 ... choose. 18:02:16 jcraig: leaving a note for sarah and MattKing to consider 18:02:36 ... I think we would still want fire the creation event 18:02:39 ... and align the spec 18:02:51 ... and JAWS could choose to ignore if they think it’s irrelevant 18:03:51 s/that sounds dangerous/it sounds dangerous to make the change in one engine, where other engine have aligned on a different behavior/ 18:04:02 one thing that can be a problem is when alert is given an accname (becuase it can be named LOL) and should that count as an auto announcement, or should that be ignored until content is inserted into the alert? 18:04:34 present+ 18:04:40 zakim, end meeting 18:04:40 As of this point the attendees have been pkra, Francis_Storr, aardrian, Summer, Adam_Page, scotto, giacomo-petri, Daniel, katez, melsumner, keithamus, CurtBellew, CoryJoseph, 18:04:43 ... jcraig, TheoHale 18:04:43 RRSAgent, please draft minutes v2 18:04:45 I have made the request to generate https://www.w3.org/2024/04/18-aria-minutes.html Zakim 18:04:52 I am happy to have been of service, Adam_Page; please remember to excuse RRSAgent. Goodbye 18:04:52 rrsagent, draft minutes 18:04:53 I have made the request to generate https://www.w3.org/2024/04/18-aria-minutes.html dmontalvo 18:04:58 Zakim has left #aria 18:05:13 s/other engine have aligned on a different behavior/other engines have aligned on a different behavior, and live regions are not yet testable in WPT. there's a real risk here of making the existing problems even worse across browser and screenreader combinations./ 18:05:26 rrsagent, make minutes 18:05:27 I have made the request to generate https://www.w3.org/2024/04/18-aria-minutes.html jcraig 18:08:03 JAWS/NVDA monitor live regions on text insertion, not on creation. We have cases where live regions are being created with the intended text to be spoken and JAWS/NVDA are not speaking that text but Chromium through UIA was firing a live region causing Narrator (based solely on UIA) to speak the content on creation. This caused a very different 18:08:03 interaction based on the screen reader. After conversion with Mick from NV Access he explained the intent was to only speak on text insertion (which is what they do) and agreed that the UIA implementation was inconsistent with that intent. 18:10:54 present+ Doug 18:11:07 present+ sarah 18:11:10 present+ MattKing 18:11:15 rrsagent, make minutes 18:11:16 I have made the request to generate https://www.w3.org/2024/04/18-aria-minutes.html Adam_Page 18:36:55 <\join_subline> \join_subline has joined #aria 19:31:37 <\join_su1line> \join_su1line has joined #aria 19:53:32 Note for the minutes that several substitutions (scribe corrections) are listed in the minutes as "Succeeded" but the changes did not actually make it into the minutes... I'm not sure why. Please review the IRC log needed. 19:53:43 rrsagent, make minutes 19:53:44 I have made the request to generate https://www.w3.org/2024/04/18-aria-minutes.html jcraig 21:42:27 jongund has joined #aria 23:46:37 jongund has joined #aria