17:00:04 RRSAgent has joined #aria 17:00:08 logging to https://www.w3.org/2024/05/23-aria-irc 17:00:08 RRSAgent, make logs Public 17:00:09 Meeting: ARIA WG 17:00:15 agendabot, find agenda 17:00:15 spectranaut_, OK. This may take a minute... 17:00:16 agenda: https://www.w3.org/events/meetings/2b57854a-65cb-421e-b9e0-f9a8da31f160/20240523T130000/ 17:00:16 clear agenda 17:00:16 agenda+ -> New Issue Triage https://bit.ly/3K9bzS7 17:00:16 agenda+ -> New PR Triage https://bit.ly/3V8Ve60 17:00:18 agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y 17:00:25 agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates 17:00:25 agenda+ Monorepo status 17:00:26 agenda+ -> Consider loosening 'requirements' for naming certain container elements https://github.com/w3c/aria/issues/2180 17:00:29 agenda+ -> Why does not allow role? https://github.com/w3c/html-aam/issues/546 17:00:32 agenda+ -> CSS: handing the a11y of anchor positioning https://github.com/w3c/html-aam/issues/545 17:00:35 giacomo-petri has joined #aria 17:00:40 present+ 17:01:26 aardrian has joined #aria 17:01:52 katez has joined #aria 17:01:55 present+ 17:01:57 present+ 17:02:06 present+ 17:02:07 present+ 17:02:28 chair: ValerieYoung 17:02:29 present+ 17:02:38 present+ 17:02:47 sarah has joined #aria 17:02:50 ray-schwartz has joined #ARIA 17:03:01 jocelyntran has joined #aria 17:03:19 pkra has joined #aria 17:03:22 scott has joined #aria 17:03:25 present+ 17:03:32 present+ 17:03:36 present+ 17:04:03 present+ 17:04:06 scribe+ 17:04:13 zakim, first item 17:04:13 I don't understand 'first item', sarah 17:04:28 zakim, next item 17:04:28 agendum 1 -- -> New Issue Triage https://bit.ly/3K9bzS7 -- taken up [from agendabot] 17:04:45 zakim, close this item 17:04:45 agendum 1 closed 17:04:46 fofila has joined #aria 17:04:47 I see 7 items remaining on the agenda; the next one is 17:04:47 2. -> New PR Triage https://bit.ly/3V8Ve60 [from agendabot] 17:04:52 zakim, next item 17:04:52 agendum 2 -- -> New PR Triage https://bit.ly/3V8Ve60 -- taken up [from agendabot] 17:05:41 spectranaut_: I think these are all monorepo PRs or from us 17:05:51 spectranaut_: we'll talk about the monorepo soon 17:06:08 spectranaut_: one aria-hidden PR from scott 17:06:15 Present+ 17:06:34 scott: this is trying to resolve the expectation around aria-hidden and focusable items. So if you have a container with aria-hidden and a button within. Talking with Aaron on this, and trying to get this closed 17:06:39 spectranaut_: any other reviewers? 17:06:55 siri has joined #aria 17:07:10 scott: this is closing the issue I opened, but also related to work Melanie and Aaron were trying to do with the giant aria-hidden PR. I went in a bit of a different direction, but it's all based off the same ideas 17:07:21 Adam_Page: I'm interested, could also do WPT coverage 17:07:42 Rahim: I believe this is testable, maybe we could create a separate issue? I can follow up 17:07:55 zakim, next item 17:07:57 agendum 3 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot] 17:08:08 spectranaut_: nothing new, moving on 17:08:13 zakim, next item 17:08:13 agendum 3 was just opened, sarah 17:08:16 zakim, close this item 17:08:16 agendum 3 closed 17:08:17 I see 5 items remaining on the agenda; the next one is 17:08:17 4. -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates [from agendabot] 17:08:18 zakim, next item 17:08:19 agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 17:08:36 spectranaut_: this morning, had ariaNotify deep dive. Would be good to share the slides 17:08:58 https://docs.google.com/presentation/d/1dZYiHdf1k0km4U5ZVlGa6QzgLrkcYOoNXzxwyhsln0g/edit#slide=id.g2dfa6629443_2_85 17:09:15 spectranaut_: I don't think we have anything planned upcoming. Anything we want to plan? 17:09:41 (silence) 17:09:44 spectranaut_: moving on 17:09:48 zakim, next item 17:09:48 agendum 5 -- Monorepo status -- taken up [from agendabot] 17:10:29 spectranaut_: monorepo work is in progress. There are a lot of PRs on ARIA, these are PRs that are moving the history of the individual specs into the ARIA repo. 17:10:51 spectranaut_: there are PRs by Peter that are moving the PRs from the old specs to the ARIA branch. We are doing those one by one, I think Peter might do all of them for us. 17:11:18 pkra: I cannot do those where branches are not in the repository. Well, I'd rather not. Those are not a lot, I think the only one on the call is Sarah 17:12:18 spectranaut_: we're planning on finishing this work by next week on tuesday. If everyone can hold off on doing new work till then, it will make it easier to finish. On tuesday we won't be merging the PRs, because they're in various states. The editors of all the specs should decide how they want to handle the description of these individual PRs 17:12:21 spectranaut_: more to come 17:12:39 spectranaut_: any questions, or James and Peter is there anything else to talk about? 17:12:56 pkra: if you want to make a PR to the ARIA spec, that won't cause any issues. If you do one to other ones, we might miss them 17:13:11 keithamus: are there any guidelines to making a PR like the core AAM one? 17:13:37 spectranaut_: the goal is to have one PR for cross-spec changes 17:14:07 pkra: you can do it yourself, but you'd need to wait until the Core AAM spec is moved over 17:14:36 spectranaut_: we will have a PR preview. It's not the same bot so the diff option won't be available. It's using Netlify. 17:15:09 spectranaut_: we have a long list of follow-up tasks that we will convert to issues so other folks can see what needs to be done still. Feel free to provide feedback on the process in the future 17:15:19 zakim, next item 17:15:19 agendum 6 -- -> Consider loosening 'requirements' for naming certain container elements https://github.com/w3c/aria/issues/2180 -- taken up [from agendabot] 17:16:33 scott: this came out of the editors meaning we had, and was brought up in previous ARIA meetings. I filed this issue per the conversation in the WCAG group where giacomo-petri asked if it was a WCAG failure if a table or dialog is not named if using the native HTML elements that don't require names vs. the ARIA ones that do require them. 17:17:25 scott: the line between what is an ARIA requirement and what is a WCAG requirement can confuse people. So that was the setup for this. By making this a requirement, we are saying that even in instances where naming these things could be redundant to other ways of identifying the containers -- a radiogroup could have radios that are fully 17:17:25 understandable by themselves, same for headings before tables and dialogs 17:18:23 scott: e.g. in a dialog that has a heading that is auto-read, having it be the name can be redundant. So we have a failure that doesn't always lead to a negative user experience. My suggestion here is the requirement should be changed. I think it's usually a good idea to name these things, but I don't agree with having a requirement that 100% they 17:18:23 should all be named 17:18:33 scott: it sounded like in the editor's meeting people might've kind of agreed with me 17:19:01 giacomo-petri: that's perfect, and I'm also working on an ACT rule that's checking these. I've removed all the elements with an implicit role from the rule. 17:19:29 giacomo-petri: then, as Scott said, if we set this as a requirement for implicit roles, this means that all tables, forms, need an explicit name regardless of if it's implicit role, which is not always necessary 17:19:46 scott: it's not always a compliance failure if they don't have a name. If it is, it would be caught by one of the existing WCAG rules. 17:20:15 present+ 17:20:18 scott: I've been taking that approach and slowly updating ARIA in HTML to be less strict, because not all the rules in there need to be as strict as they are. Some of those were done before conformance checkers being as robust as they are now 17:20:22 A+ 17:20:28 A+ 17:20:47 Q+ 17:20:59 s/A+// 17:21:02 s/A+// 17:21:03 scott: one of Steve's goals was that the spec was made to ensure that ARIA and HTML would play well together. some of the rules were about not using ARIA, just use native HTML. Now that things have evolved, that is not really a problem anymore and where issues can pop up, there is already a WCAG requirement for it 17:21:17 q+ 17:21:22 ack CoryJoseph 17:22:12 CoryJoseph: I agree with everything you're saying, but I can't think of an example where a dialog would be acceptable without a name. I agree we shouldn't be more stringent than wcag, so if wcag doesn't say a dialog has to have a name, then OK. Is there a situation where a dialog could be acceptable without a name? 17:22:48 scott: a standard confirmation dialog in many native apps doesn't have a name. Taking that same concept to the web, a sign-in dialog where the first heading is "sign in", does that dialog also need to be named sign in, when the heading is right there that's going to be the first thing a screen reader reads? 17:23:15 CoryJoseph: I guess from my perspective, I'm thinking if you have the heading there, why wouldn't you say the heading is the name of the dialog? I see your line of thinking, I think there should be name for dialogs 17:23:51 scott: we do also have the effort of trying to implicitly name things from headings, including article and dialog. If that were the case, if they grabbed the first heading and made it the name, then it would be named. THen also, screen readers could put in their logic to not repeat the name. 17:24:17 scott: so depending on how someone gets to the dialog, they might hear the name, and then the heading immediately. 17:24:18 ack Rahim 17:25:11 Rahim: quick question on if this has any impact on authoring practices, the APG guide. There's language for a lot of components like radiogroup, dialog where they say if there's a visible title use aria-labelledby and otherwise use aria-label. There's no indication that it's not required, should there be any crossover to updating that guidance? 17:25:22 q+ 17:25:27 scott: there should probably be something there to call out that these are ARIA requirements and not WCAG requirements 17:25:51 Rahim: APG has that section on keyboard operability, so some of those are optional, but other places like the ARIA table does not have any indication that they're optional 17:26:00 ack siri 17:26:51 siri: I think there are cases where the dialog name is requirement, for example if you send any feedback like thumbs up, if there's a dialog that requires more information on why you sent the feedback. In that case, if the dialog doesn't have a good label, then users don't get the same information as visual users 17:27:03 q+ 17:27:08 siri: why do we not want a dialog name when we have aria-labelledby and have it map to the heading? 17:27:53 scott: whether it's aria-label or aria-labelledby is not what we're talking about right now. It's whether all dialogs, radiogroups, tables, grids don't always require a name. I'm not arguing that there aren't cases where things do need names, the issue is that this is a pass/fail boolean right now, and we're saying that these always need a name and 17:27:53 that's not true 17:28:26 ack giacomo-petri 17:28:31 scott: just want to be absolutely clear that I'm not saying dialogs don't require names, that would be a misunderstanding. I still agree that in most cases, it would be good, and people should provide names to these things. I think it's an overreach to say they're always required 17:28:49 q+ 17:29:15 giacomo-petri: I think we can go further in which roles we exclude from the requirement. For example, we have a search form, with a form input inside, with label search, and so with a screen reader, you 'd find search landmark, search form, search input, 17:29:40 giacomo-petri: I'm not saying we never need the name on specific elements. We could even determine which elements might or might need the accname, but I think the example with the search is pretty self-explanatory 17:29:42 ack spectranaut_ 17:30:15 spectranaut_: just wanted to say that I agree with this change, I feel like if we want them to be requirements we should agree with WCAG. I think there are some scenarios where the context is enough for the names of some of these elements, and we should allow for that. I just wanted to voice support. 17:30:32 Q+ 17:30:38 spectranaut_: there's a little bit of pushback from Cory, but is there any other feelings on this? 17:30:42 ack aardrian 17:30:51 aardrian: I also support this for the reasons scott outlined. This isn't wcag, I"m good with this 17:31:07 CoryJoseph: just a follow up on my statements, I think aligning with not being more strict than WCAG, I would support it 17:31:19 +1 as optional 17:31:24 spectranaut_: no other pushback or disagreement? I think we should open a PR and discuss individual elements 17:31:39 scott: jamesn I want to pick on you 17:31:59 scott: you had the strongest arguments against this, if there's an argument to continue to require this, I'm happy to to reconsider 17:32:08 jamesn: I've heard enough, I no longer hold that opinion 17:32:22 spectranaut_: next steps, someone want to volunteer? 17:32:37 scott: I'll do it once the repo's calmed down. 17:32:51 jamesn: PRs on the ARIA spec are fine, since it's the one that isn't moving, right pkra? 17:32:56 pkra: last we decided, yes 17:33:05 zakim, next item 17:33:05 agendum 7 -- -> Why does not allow role? https://github.com/w3c/html-aam/issues/546 -- taken up [from agendabot] 17:33:31 spectranaut_: keithamus, why does slot not require role? This is an issue on HTML AAM 17:34:26 keithamus: so, you can't put role on slot which feels weird because it's often interleaved with other things that have roles. We made a mistake with a package we were workign on because we changed a div to a slot, and then we noticed the issue and had to do a larger refactor around that 17:34:45 keithamus: the only things that don't allow a role are things that go in the head which feels right, but slot feels weird with that 17:34:54 q+ 17:35:21 Q+ 17:35:24 spectranaut_: should we start off with the context from scott from last time? Though you can see from the issue that slot isn't supposed to be exposed to the user at all, so this would change things 17:35:28 q+ 17:35:40 ack sarah 17:35:56 Q- 17:36:09 sarah: is it currently exposed in the layout tree right now? 17:36:16 ack scott 17:36:20 keithamus: you can override the display: contents and make it part of the layout tree if you want it to be 17:36:21 scott 17:36:59 scott: for all the opposition when we brought this up, I actually don't care. Just when I brought this up, I was told no. If opinions have changed and HTML editors are supportive of this then fine. I don't see us making this change without getting wider support 17:37:34 scott: to give this a role is kind of going against what the element is defined by. Even per the example that you can add styles to it, you can do that to head content too but that doesn't mean you should. I don't know that that's a strong enough argument there 17:37:59 keithamus: I guess the next step then is to take this to whatwg, which I'm happy to do and prod them a bit until someone tells me a firm no 17:38:21 keithamus: if I do get a no, I can have a good followup action to add words to the spec about how this is a weird case where you can't add a role 17:38:47 scott: right now I have to show a thread from a validator to show the explanation I was given 17:39:16 jamesn: I understand there was a time when mistakenly a role got applied to a slot in some real code at some point, but was this a complex workaround to not do this? I'm struggling to see the benefit of moving that way 17:39:48 q+ 17:39:59 keithamus: I think in this situation, we had a div role=tablist which can only have direct children. I don't think slot counts, but we had some difficulty, and I think ultimately we used javascript to apply the role depending on whether or not the element is slotted, so not a wonderful workaround 17:40:08 keithamus: the more I get told probably no, I think I need a definitely no 17:40:24 jamesn: it isn't something I've heard from our web component folks, but maybe they just haven't raised it 17:40:37 keithamus: I'm just in a weird position where I know enough to be dangerous, and here we are 17:40:40 ack scott 17:41:51 scott: some of the contextual role stuff that's going on -- in Firefox specifically, I know that if slot is exposed in their tree as a generic, then right now, and I think this a bug they need to fix, but right now if a slot is in a
    and exposed as generic, then that means all the li elements see that generic as their parent and then think 17:41:51 they're not inside a list and turn into generics. So that's a situation where slot being exposed as a role breaks the accessibility of the list 17:42:09 scott: so that's a place where if slot was role=none, or no role, this wouldn't have happened 17:42:14 q+ 17:42:23 ack sarah 17:42:25 ack me 17:43:40 sarah: would the new change where you can have generics between tablist and tab, so even if slot had a display it would be OK. Would that have helped your use case? 17:43:46 keithamus: I need to think about it more, maybe 17:44:11 Q+ 17:44:13 jamesn: I wasn't aware you could change the display, maybe that should change things? 17:44:24 keithamus: scott's argument was that you can also do that for script elements 17:44:48 script, link, title, head, style... anything that is essentially display none by default 17:45:11 keithamus: dunno if I want to open the floodgates on all of these, my thoughts are that slots are interleaved between other elements, so it can be difficult to massage the nodes 17:45:14 ack aardrian 17:46:04 aardrian: was going to parrot what keithamus said, where people do display the code, the script and style block. My thought was that those are edge cases and we don't need to panic about those. I would like to think that we don't need to worry about putting a display on a slot, but I could see a developer doing that. I don't know if that means we 17:46:04 need to allow role on it 17:46:46 keithamus: I think that depending on the conclusion from someone telling me no, I think I'll ask chrome to put a big warning on putting a role on a slot, because we did make this change, and shipped it, and didn't notice until getting an axe warning 17:47:00 spectranaut_: I think that sounds like a good resolution unless anyone doesn't want keith to do that, let's move on 17:47:02 zakim, next item 17:47:02 agendum 8 -- -> CSS: handing the a11y of anchor positioning https://github.com/w3c/html-aam/issues/545 -- taken up [from agendabot] 17:47:33 spectranaut_: another one from scott, he left 17:47:48 spectranaut_: anyone else have context on this issue? 17:48:07 pkra: and it's very future looking still, anchor positioning isn't widely available, is it? 17:48:23 spectranaut_: I wouldn't mind ending early, any parting comments or should we just run away? 17:49:10 Going to drop off -- bye! 17:51:22 zakim, end meeting 17:51:22 As of this point the attendees have been giacomo-petri, aardrian, katez, knights, Rahim, Francis_Storr, jamesn, pkra, Adam_Page, jocelyntran, ray-schwartz, CoryJoseph, keithamus 17:51:25 RRSAgent, please draft minutes v2 17:51:27 I have made the request to generate https://www.w3.org/2024/05/23-aria-minutes.html Zakim 17:51:34 I am happy to have been of service, sarah; please remember to excuse RRSAgent. Goodbye 17:51:34 present+ 17:51:34 rrsagent, make minutes 17:51:35 I have made the request to generate https://www.w3.org/2024/05/23-aria-minutes.html sarah 17:51:41 Zakim has left #aria