18:16:13 <RRSAgent> RRSAgent has joined #aria-apg
18:16:17 <RRSAgent> logging to https://www.w3.org/2025/10/21-aria-apg-irc
18:16:17 <Zakim> RRSAgent, make logs Public
18:16:18 <Zakim> Meeting: ARIA Authoring Practices Task Force
18:16:20 <jugglinmike> present+ jugglinmike
18:16:24 <jugglinmike> scribe+ jugglinmike
18:16:32 <jugglinmike> present+ Adam_Page
18:16:34 <jugglinmike> present+ arigilmore
18:16:38 <jugglinmike> present+ CurtBellew
18:16:43 <jugglinmike> present+ jongund
18:16:48 <jugglinmike> present+ siri
18:17:16 <jugglinmike> Topic: Setup and Review Agenda
18:17:37 <jugglinmike> present+ Matt_King
18:17:58 <jugglinmike> Matt_King: Next meeting: October 28
18:17:59 <Siri> Siri has joined #aria-apg
18:18:14 <Siri> Present+
18:29:22 <jugglinmike> Topic: Publication planning
18:29:59 <jugglinmike> Adam_Page: I checked out spin button in production, and it appears to be working as expected. I didn't leave a comment, though
18:30:05 <jugglinmike> arigilmore: I checked on menu, and it looks good
18:30:12 <jugglinmike> Matt_King: Thank you; those were the two I wanted to check on
18:30:33 <jugglinmike> Matt_King: I think October 29 is too aggressive for our next publication date, so I'll move it out
18:30:49 <jugglinmike> Matt_King: It would be nice to get it out before TPAC, but we'll see. We'll discuss it next week
18:30:58 <jugglinmike> Topic: Issue 3193: listbox example with aria-actions
18:31:06 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3372
18:31:36 <jugglinmike> Matt_King: First of call, CurtBellew: thank you so much for the progress you've already made. It's starting to look pretty great!
18:32:00 <jugglinmike> Matt_King: I left a comment with some discussion items
18:32:08 <jugglinmike> Matt_King: The first is about what the browser is doing to name the options
18:32:25 <jugglinmike> Matt_King: The issue specifically said, "let's test the meaning of aria-actions=''"
18:32:42 <jugglinmike> Matt_King: That is supposed to communicate that actions are available
18:33:24 <jugglinmike> Matt_King: When you're in JAWS "forms mode", you only get one of the options. You can't get any information about the options that don't have focus
18:33:41 <jugglinmike> Matt_King: I don't know if this is working for items that don't have focus
18:33:57 <jugglinmike> CurtBellew: I was the same way. I can see it happening in the code, but I don't know how to test it
18:34:09 <jugglinmike> Matt_King: I just realized that I can test it with the JAWS touch cursor
18:34:37 <jugglinmike> Matt_King: Here's the naming problem, though: Chrome calculates the name of an option from its content (unless we apply aria-label, which we don't want to do in this case)
18:35:13 <jugglinmike> Matt_King: Because the HTML has the buttons at the time the page loads, Chrome is calculating the name of all of those options to include the name of all the buttons because they are in the content
18:35:31 <jugglinmike> CurtBellew: I wonder about looping back around and using aria-labeledby
18:35:43 <jugglinmike> CurtBellew: I created a test on that, but I haven't been able to reply, yet.
18:35:57 <jongund> jongund has joined #aria-apg
18:36:00 <jugglinmike> Matt_King: That kind of breaks the intent to determine whether Chrome is doing the right thing with the naming algorithm
18:36:31 <jugglinmike> Matt_King: My guess is that when we were talking about this in ARIA, that we would assume that the JavaScript would add the buttons to the element in real-time.
18:36:47 <jugglinmike> Matt_King: In this case, the IDs are actually there, so you could specify aria-actions with all the IDs
18:37:26 <jugglinmike> Matt_King: So, when we made this part of the spec (where aria-actions="" means something), my assumption was that it was supposed to support a use-case where the IDs are not available
18:37:48 <jugglinmike> CurtBellew: I'm not averse to that. I thought we wanted these to be basically "display: none" and then come into view when they were focused
18:37:56 <jugglinmike> CurtBellew: But I think it would work the same way either way
18:38:09 <jugglinmike> Matt_King: They are "display: none". Does that mean that Chrome has a bug?
18:38:35 <jugglinmike> Matt_King: If you have aria-actions specified before they are displayed... Is this an order-of-operations thing?
18:38:55 <jugglinmike> Matt_King: What if you just disabled the method that sets the value of aria-actions? Would you still get the names of the buttons?
18:39:15 <jugglinmike> Matt_King: I'm thinking that there is a bug in the name-from-content algorithm and that Chrome is leaving out the content
18:39:56 <jugglinmike> Siri: This is one thing I see a lot. If you use "display: none", how does the screen reader know that there are extra actions?
18:40:19 <jugglinmike> Matt_King: When you're in "reading mode" or a "touch cursor mode", JAWS will tell you there are actions because aria-actions=""
18:40:31 <jugglinmike> Siri: But they are empty until you focus on it
18:41:03 <jugglinmike> Matt_King: Right. When the screen reader wants to get the actions, what they're supposed to do is first focus the item, and then look at the value of aria-actions. So focusing the item is supposed to reveal the actions
18:41:28 <jugglinmike> Siri: The first one is none, and it doesn't have any actions.
18:42:28 <jugglinmike> Matt_King: JAWS has an experimental command (if you have an experimental flag enabled in Chrome) where, if you have all these conditions met, JAWS will tell you that you have actions even if the actions aren't specified, yet
18:43:12 <jugglinmike> Matt_King: This is an interesting thing. We don't want the name to be in...
18:43:29 <jugglinmike> Adam_Page: I'm looking at the preview, now, and I'm seeing that the buttons which are referenced by aria-actions are nested within the option
18:43:57 <jugglinmike> Adam_Page: ...that is different than my initial tabs example, where I purposely did not nest them in that way. I had to make them siblings because I was dealing with natively-focusable elements
18:44:07 <jugglinmike> Adam_Page: Where in this example, you are using aria-activedescendent
18:44:42 <jugglinmike> Matt_King: That's what Sarah had said with tree-items. It's why we have a change to the naming algorithm with aria-actions. Sarah expected that normally items would be nested like that
18:44:57 <jugglinmike> Adam_Page: I'm translating this to native HTML concepts in my mind, so to me, and option is focusable
18:45:04 <jugglinmike> CurtBellew: It was definitely a shift for me
18:45:17 <jugglinmike> Matt_King: Do you think we should have the buttons inside the listbox but outside the options?
18:45:40 <jugglinmike> Adam_Page: Yes, that cognitively makes more sense to me, and it also sidesteps the accessible name problem
18:46:10 <jugglinmike> Matt_King: Even though they are focusable, if they contain a group and if it's a parent tree-view item, then the parent has to contain a group which is the child nodes
18:46:20 <jugglinmike> Matt_King: So you're normally putting focusables inside focusables
18:46:33 <jugglinmike> Matt_King: It sounds like, for listbox, you're saying that it feels unnatural to place them inside the option
18:46:48 <jugglinmike> Adam_Page: That's right, but I trust Sarah. I should review that discussion
18:47:05 <jugglinmike> CurtBellew: I had the same response as Adam_Page, but I missed the discussion (I believe it was a TPAC)
18:47:22 <jugglinmike> Siri: I wish we had some information. It seems like these are used a lot
18:47:57 <jugglinmike> Matt_King: I'm noticing that with the touch cursor, JAWS is not telling me that the elements have actions, and it's also not including the names of the hidden buttons inside the names of the options
18:48:52 <jugglinmike> Matt_King: If I activate one of these... Now, it is including it in the name. That seems like a Chrome bug, unless again, this is a timing issue. What I did was I activated with the touch cursor, and now I have the element being selected and the name of that element (including the name of all the buttons)
18:49:44 <jugglinmike> Matt_King: I don't know whose bugs these are, but I think the naming thing is something that we need to figure out. What the intent of the spec is, at least
18:49:54 <jugglinmike> Matt_King: I wonder if aria-actions is again on the agenda this week
18:50:04 <jugglinmike> CurtBellew: I should be able to attend the ARIA Working Group meeting this week
18:50:28 <jugglinmike> CurtBellew: I could ensure the timing that you're talking about happens--that the activedescendent gets updated and that then we set the actions
18:50:39 <jugglinmike> Matt_King: It seems like we need to set the ID of the actions before the options are visible
18:50:43 <jugglinmike> CurtBellew: Ah, yes, that's what I meant
18:51:34 <jugglinmike> Matt_King: If you make the buttons visible, and Chrome calculates the name as a result of that, and then you add the value of aria-actions, then is Chrome going to re-calculate the name after that?
18:51:54 <jugglinmike> Matt_King: Maybe that's the question for the ARIA Working Group--"what is the expectation, here?"
18:52:15 <jugglinmike> CurtBellew: It feels like it won't recognize that the IDs exist or, as you said, it will just sort of re-calculate, and you'll get what we have, now
18:52:41 <jugglinmike> Matt_King: The touch cursor is also seeing all the icons--the graphics. We probably want to hide those with aria-hidden
18:52:52 <jugglinmike> Siri: It's reading all the names of the buttons that show up?
18:52:59 <jugglinmike> Matt_King: Yeah, that's one of the problem
18:53:18 <jugglinmike> Matt_King: It feels like it's really janky to place the buttons inside of the element
18:53:46 <jugglinmike> Matt_King: Maybe aria-actions="" doesn't apply in that scenario. Maybe if you're going to place the buttons inside of the element, you need to...
18:53:53 <jugglinmike> Adam_Page: ...have a persistent relation?
18:53:57 <jugglinmike> Matt_King: Maybe...
18:54:12 <jugglinmike> Matt_King: I really wonder about the intent. I feel a lot of confusion here
18:54:36 <jugglinmike> Matt_King: In the mean time, if you could place aria-hidden on those icons (just like we already use it with the "checked") icon
18:54:38 <jugglinmike> CurtBellew: Got it
18:55:21 <jugglinmike> Matt_King: What do we want to do when someone has marked something a "favorite"? I wonder if the favorite icon should be first or last within the name. It seems like it should be part of the name because it's not a state
18:55:46 <jugglinmike> CurtBellew: Right now, it's just using an aria-pressed, so that makes sense!
18:56:11 <jugglinmike> Adam_Page: This is where a relatable real-world example could be helpful. It's feeling a little contrived right now. Who's out there favoriting elements?
18:57:43 <jugglinmike> CurtBellew: I have a few bullet points to take care of, so I'll dot hat
18:57:48 <jugglinmike> s/dot hat/do that/
18:58:11 <jugglinmike> Adam_Page: This might be a good opportunity to use text alternatives for CSS "content" in pseudo-elements
18:58:36 <jugglinmike> Adam_Page: It's a special syntax for the "content" property for the CSS "content" attribute
18:58:57 <jugglinmike> Matt_King: Adam_Page, can you make a suggestion for CurtBellew in the "files" tab of the GitHub pull request?
18:59:01 <jugglinmike> Adam_Page: Sure
18:59:15 <jugglinmike> Siri: Could you add a link to the IRC chat, as well?
18:59:32 <jugglinmike> Matt_King: Okay, we're out of time. Thanks everyone! We'll meet same time, same station next week
18:59:55 <jugglinmike> Zakim, end the meeting
18:59:55 <Zakim> As of this point the attendees have been jugglinmike, Adam_Page, arigilmore, CurtBellew, jongund, siri, Matt_King
18:59:57 <Zakim> RRSAgent, please draft minutes v2
18:59:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/21-aria-apg-minutes.html Zakim
19:00:05 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
19:00:05 <Zakim> Zakim has left #aria-apg
19:02:23 <jugglinmike> rrsagent, leave
19:02:23 <RRSAgent> I see no action items