15:54:56 <RRSAgent> RRSAgent has joined #aria-apg
15:55:00 <RRSAgent> logging to https://www.w3.org/2026/05/13-aria-apg-irc
15:55:00 <Zakim> RRSAgent, make logs Public
15:55:01 <Zakim> Meeting: ARIA Authoring Practices Task Force
16:01:57 <Matt_King> Matt_King has joined #aria-apg
16:01:57 <Adam> Adam has joined #aria-apg
16:02:32 <CurtBellew> CurtBellew has joined #aria-apg
16:03:12 <jongund> jongund has joined #aria-apg
16:03:12 <jugglinmike> jugglinmike has joined #aria-apg
16:03:12 <Matt_King> Matt_King has joined #aria-apg
16:03:12 <Adam> Adam has joined #aria-apg
16:03:14 <Siri> Siri has joined #aria-apg
16:03:19 <Daniel> present+
16:03:29 <jugglinmike> present+ jugglinmike
16:03:31 <jugglinmike> scribe+ jugglinmike
16:03:39 <jugglinmike> present+ Siri
16:03:43 <jugglinmike> present+ CurtBellew
16:03:54 <jugglinmike> present+ jongund
16:04:30 <Daniel> rrsagent, draft minutes
16:04:31 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/13-aria-apg-minutes.html Daniel
16:05:13 <jongund> jongund has joined #aria-apg
16:05:13 <jugglinmike> jugglinmike has joined #aria-apg
16:05:13 <Matt_King> Matt_King has joined #aria-apg
16:05:13 <Adam> Adam has joined #aria-apg
16:05:16 <jugglinmike> Matt_King: Publication planning
16:05:30 <jugglinmike> Matt_King: In the milestone, there are six pull requests. Four of them are merged and ready to go
16:06:56 <jongund> jongund has joined #aria-apg
16:06:56 <jugglinmike> jugglinmike has joined #aria-apg
16:06:56 <Matt_King> Matt_King has joined #aria-apg
16:06:56 <Adam> Adam has joined #aria-apg
16:07:03 <jugglinmike> Matt_King: Okay, then I will do that later today
16:07:06 <JoeLamyman> JoeLamyman has joined #aria-apg
16:07:18 <jugglinmike> Matt_King: Now, for the two in active review, we have a listbox with tabs and the color settings ones
16:07:26 <jugglinmike> Matt_King: Maybe we should do a quick check on each of these two
16:07:28 <JoeLamyman> present+
16:07:50 <jugglinmike> Subtopic: PR 2991: Add Practice Page for Supporting Color Contrast Settings by mcking65
16:07:55 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/2991
16:08:09 <jugglinmike> Matt_King: Here, jongund has made updates, so it's ready for the next round of review
16:08:22 <jugglinmike> jongund: Yeah, I'm caught up on all the feedback I've received to date
16:08:30 <jugglinmike> Matt_King: We're looking for feedback from a few people
16:08:45 <jugglinmike> Matt_King: The person who last requested changes was Adam
16:09:05 <jugglinmike> Matt_King: jongund, if you've responded to those changes, then I think I should re-request review from Adam. I've done that just now
16:09:45 <jugglinmike> Matt_King: We haven't had participation from Sarah in a while. I wonder if she could look again because she had a lot of input before...
16:10:04 <jugglinmike> Matt_King: It would be great if we could get Sarah's input on the current state
16:10:12 <jugglinmike> Matt_King: howard-e is also on the list of reviewers
16:10:26 <jugglinmike> Matt_King: CurtBellew and JoeLamyman, both of your names are on here. Are you able to do those reviews?
16:10:32 <jugglinmike> JoeLamyman: Yes
16:10:36 <jugglinmike> CurtBellew: Yes
16:10:47 <jugglinmike> Matt_King: I think all of your feedback has been incorporated, JoeLamyman
16:10:51 <jugglinmike> JoeLamyman: Awesome, thank you
16:11:12 <jugglinmike> Matt_King: It seems like I should reach out to people directly and find out if they are available (and remove them from the "reviewers" list if they are not)
16:11:26 <jugglinmike> Subtopic: PR 3400: Revise Content for New Experimental Example of Scrollable Listbox with Actions on Options by mcking65
16:11:31 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3400
16:11:41 <jugglinmike> Matt_King: This is the one that CurtBellew is working on--updating the aria-actions listbox
16:11:50 <jugglinmike> CurtBellew: I've made all three changes that we discussed last time
16:12:27 <jugglinmike> CurtBellew: jongund made a suggestion on the visual side. I didn't implement it exactly, but I think the change I made is in the spirit of his suggestion
16:13:44 <jugglinmike> Matt_King: Okay, so for reviewers... There aren't actually any reviewers assigned on this.
16:14:23 <jugglinmike> Matt_King: We aren't merging this one into main; we're merging it into another pull request branch. That's because that is the branch that is referenced by another issue in ARIA. So we don't have to have a formal review process here.
16:14:49 <jugglinmike> Matt_King: If we're comfortable with the amount of feedback we've received so far, we can merge it to update pull request #3372
16:16:10 <jugglinmike> Siri: As soon as the focus is placed on the list box, you have to use the up and down arrow to traverse. I'm using the left and right arrow. If I use the left arrow, it goes from items to the star, but if I press left again, I feel like focus goes to the entire list box, but I'm not sure
16:16:25 <jugglinmike> CurtBellew: It goes to the entire option. I see what you mean
16:16:40 <jugglinmike> CurtBellew: There's no change in the visual presentation
16:17:23 <jugglinmike> Matt_King: I think I understand. When you take it off of the star and go back to the whole item, the "sub-focus" (the focus on the thing inside the item) disappears and gives the feeling that something was lost.
16:17:34 <jugglinmike> Matt_King: I feel like that's the correct behavior. You still have the focus ring
16:17:45 <jugglinmike> CurtBellew: We could change the appearance of the focus
16:18:05 <jugglinmike> Matt_King: Yeah. You still want to keep some kind of ring around the whole item because it's a composite. It's like focusing within a row
16:18:39 <jugglinmike> Siri: When the focus is on the star, when I tab, the focus goes to the next item on the page
16:18:43 <jugglinmike> Matt_King: That sounds like a bug
16:18:47 <jugglinmike> CurtBellew: I see what you mean
16:19:38 <jugglinmike> Matt_King: Okay, for the first behavior you observed, Siri, let's make a decision. Should we leave it as-is and see if it is confusing to others (based on any feedback we receive), or is it clearly going to be a problem (that is: should we address it right now)?
16:20:23 <jugglinmike> Daniel: With VoiceOver today, what would be the actions are unlabeled. At this point, I'm not sure if we can do something for that not to happen
16:20:44 <jugglinmike> Matt_King: Hm. James said that they are fully supporting aria-actions already...
16:21:05 <jugglinmike> Daniel: I was surprised to hear that, too. I was expecting to use the native actions support, but that isn't supported in the rotor, yet
16:21:13 <jugglinmike> Daniel: This is Safari in macOS
16:21:32 <jugglinmike> Matt_King: They are definitely not unlabeled. JAWS is reading the label. I almost think it's a Safari bug. Or it may be a VoiceOver bug
16:21:56 <jugglinmike> Matt_King: Even if I look at them with the JAWS virtual cursor or the mouse cursor, they're still present and they have labels
16:22:13 <jugglinmike> Siri: For some reason it says aria-actions is empty
16:22:19 <jugglinmike> Matt_King: It should be empty when you first land on it
16:22:24 <jugglinmike> Siri: But when it shows on hover...
16:22:29 <jugglinmike> Matt_King: ...that's when it should not be empty
16:22:37 <jugglinmike> CurtBellew: On hover or on focus?
16:23:12 <jugglinmike> Matt_King: Actually, only on focus. I'm not sure that hover should popular the aria-actions attribute, but it wouldn't be wrong if it did. Focus should definitely populate the attribute
16:23:18 <jugglinmike> Siri: Okay, on focus, I'm seeing it
16:23:31 <jugglinmike> Matt_King: Back to the question of whether or not we should change the visual design of focus
16:23:54 <jugglinmike> Matt_King: I'd like to propose that we leave it as-is for now and see if we get reports from others that it is problematic
16:24:16 <jugglinmike> Matt_King: The focus behavior is acceptable. There's no WICG failure here
16:24:32 <jugglinmike> Matt_King: Not hearing any objections to that right now
16:25:02 <jugglinmike> Matt_King: The second thing Siri reported sounds like a bug. If you focus on the favorites button and tab out, then the visual focus indicator is not reviewed
16:25:08 <jugglinmike> CurtBellew: Confirmed. I will fix that
16:25:24 <jugglinmike> Siri: aria-actions, do you have to provide the ID?
16:25:32 <jugglinmike> Matt_King: Yes because it is inside the option
16:25:35 <jugglinmike> Siri: Got it, thanks
16:25:58 <jugglinmike> Matt_King: Okay, so CurtBellew, I don't know if it makes a difference whether you fix it before or after I merge this.
16:26:13 <jugglinmike> Siri: Also, the labels aren't being announced by VoiceOver
16:26:30 <jugglinmike> Daniel: It's happening seemingly randomly. We should figure out what the pattern is
16:26:42 <jugglinmike> CurtBellew: I haven't tried that in Safari at all
16:26:51 <jugglinmike> jongund: I have a Mac
16:27:12 <jugglinmike> Matt_King: Could you test it with VoiceOver and see if there are any patterns behind when labels are not getting announced?
16:27:18 <jugglinmike> jongund: Now?
16:27:27 <jugglinmike> Matt_King: When you have time
16:27:39 <jugglinmike> Topic: Issue 2438: Tablist that supports reflow
16:27:46 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/2438#issuecomment-4041766532
16:28:37 <jugglinmike> Matt_King: We discussed this two meetings ago. We came up with solutions in the meeting four weeks ago, and we proposed that we make two separate examples with two variations on a tabs list that supports reflow
16:28:56 <jugglinmike> Matt_King: I made those two sub-issues, and the goal was to make them with enough specificity that they would be "good first issues"
16:29:32 <jugglinmike> Matt_King: One of the open questions that I came up with is about the number of tabs that we should have in the example in order for it to adequately illustrate the need for reflow.
16:29:48 <jugglinmike> Matt_King: One of the things we had done previously in another pull request was to actually reduce the number of tabs
16:30:05 <jugglinmike> Matt_King: So that's the first question--it's about making the sub-issues more specific
16:30:33 <jugglinmike> Matt_King: We could discuss this now in the meeting, or someone can work with me after the meeting (I just can't make decisions on the visual aspects on my own)
16:30:54 <jugglinmike> Matt_King: To answer this question, you'd have to load up the example and do some visual experimentation to determine how many more tabs we need
16:31:02 <jugglinmike> Matt_King: Would anyone be willing to partner with me?
16:31:13 <jugglinmike> JoeLamyman: I'd be interested in helping out with this one if that's okay
16:31:16 <jugglinmike> Matt_King: That would be great!
16:31:49 <jugglinmike> Matt_King: The specs for the two sub-issues are going to be almost identical. We can start with either one of them. That's why I put the question in issue 2438--the main issue
16:32:05 <jugglinmike> s/specs/visual design specs/
16:32:27 <jugglinmike> Topic: Issue 3428: Proposal for potential accordion improvements
16:32:33 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/3428
16:32:40 <jugglinmike> Matt_King: We started the discussion of this last week
16:32:47 <jugglinmike> Matt_King: We discussed some of the proposed changes that are in there
16:33:04 <jugglinmike> Matt_King: We noticed one accessibility bug related to aria-expanded
16:33:17 <jugglinmike> Matt_King: The person who filed this has responded
16:33:42 <jugglinmike> Matt_King: I asked some follow-up questions. It seems there are two main features that the person is proposing that we may be interested in adding to the APG accordion example
16:34:08 <jugglinmike> Matt_King: The first is related to browser find, and the second is related to the way screen reader landmarks/VoiceOver rotor works
16:34:21 <jugglinmike> Matt_King: That first one is about finding content in an accordion panel that is collapsed
16:34:46 <jugglinmike> Matt_King: I think the only reason that we would want to adopt that change and make it part of the APG example is if we could justify doing so with an accessibility benefit
16:35:20 <jugglinmike> Matt_King: Do we see an accessibility benefit? Or is there another reason we should consider adopting that capability into the accordion even in the absence of an accessibility benefit?
16:36:00 <jugglinmike> CurtBellew: It seems like it would be the opposite. It seems like you wouldn't want to be something that isn't visible to be find-able
16:36:13 <jugglinmike> Matt_King: I think it could go either way. Maybe the APG should be silent
16:36:44 <jugglinmike> jongund: People may forget to do the before-match event to update states and properties. So it may be a useful way to remind readers to keep aria properties in sync as the state of the page changes
16:36:54 <jugglinmike> Matt_King: Right
16:37:53 <jugglinmike> jongund: If we ask whether this is good/bad for accessibility--this is what people do, regardless. Part of me thinks we should provide guidance. It seems like it's a good thing to add whether we think it's good to search for hidden content. My guess is that it's probably something that most people want if they're looking for specific keywords
16:38:33 <jugglinmike> Matt_King: That's a super-good point! If it's something that is done often enough, and if it has potential accessibility side-effects that we want readers to understand, then we should demonstrate it in the APG to help people avoid the "gotcha"
16:38:52 <jugglinmike> Matt_King: In that case, it would not be "scope creep" or adding unnecessary complexity to APG
16:39:47 <jugglinmike> Matt_King: Does that make sense to the rest of the crew here? That if you want stuff to be find-able, there are important things you have to do to ensure that the accessibility of the accordion doesn't break. Therefore, we should explain what those things are
16:39:51 <jugglinmike> Daniel: I think it's good advice
16:40:01 <jugglinmike> Matt_King: Okay, hearing no dissent, we can go with that
16:40:07 <jugglinmike> Matt_King: That's the find-ability thing
16:40:48 <jugglinmike> Matt_King: The next question (to which the issue author has not responded) is why we want to make the collapsed hidden panels (essentially "div" elements with a "region" role) focus-able but not in the focus order (so tab-index to -1)
16:41:16 <jugglinmike> Matt_King: But by doing that, somehow, they show up in the VoiceOver rotor. That seems problematic to me. It doesn't seem like a region that is not visible should be in the rotor
16:41:34 <jugglinmike> Matt_King: It's not 100% clear to me that is the effect of the code (I haven't tested it with my iPhone in the CodePen)
16:42:03 <jugglinmike> Matt_King: One the one hand, if you can navigate to the panels via the headings, then why not via the regions?
16:42:19 <jugglinmike> Matt_King: But somehow, navigating via the region doesn't seem to me like a good idea.
16:42:25 <jugglinmike> Matt_King: Does anyone have thoughts on that?
16:42:58 <jugglinmike> Siri: So what is the option here?
16:44:00 <jugglinmike> Matt_King: Two things. First, setting tab index to "-1" on the regions. Second: adding a focus handler to the panels (if I actually don't know whether the
16:44:35 <jugglinmike> Matt_King: It could be the case that if VoiceOver is somehow picking up on the hidden regions, then when VoiceOver is issuing the command, that would cause the region to become focusable and the handler would display it
16:45:02 <jugglinmike> Matt_King: This might be a fallback mechanism, when something is focusable but hidden. That would seem like a bug, though
16:45:35 <jugglinmike> Matt_King: They might be getting a behavior either because of a fallback mechanism or a bug (in VoiceOver or Safari)
16:45:44 <jugglinmike> Matt_King: Daniel do you have any thoughts?
16:46:15 <jugglinmike> Daniel: I'm not sure why VoiceOver is doing that (I haven't checked it enough). I agree with you, though: if it's hidden for everybody, then I don't see why it should be accessible for AT users
16:46:45 <jugglinmike> Daniel: I understand the use-case, but that's another story. That could be enabled via a plugin or a setting. But in the general case, I would advise against it
16:46:49 <jugglinmike> Matt_King: That's my intuition as well
16:47:00 <jugglinmike> Matt_King: So I think, summarizing this
16:47:26 <jugglinmike> Matt_King: As I read it, there are three changes, and there is one of the three that we think is a good addition. That is: the support for browser find
16:48:07 <jugglinmike> Matt_King: So we have some decision on what the pull request could contain. The author suggested that they could be available for that pull request
16:48:28 <jugglinmike> Topic: Issue 3439: Question about keyboard behavior in experimental tabs example
16:48:35 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/3439
16:48:53 <jugglinmike> Matt_King: This is about our current experimental tabs example (with aria-actions). It's about the keyboard behavior there
16:49:56 <jugglinmike> Matt_King: They are asking whether or not the behavior we have in this example matches the documentation. And whether or not that's what we really want
16:50:13 <jugglinmike> Matt_King: This is a little nuanced because it's related to tabbing in, changing the focus, and then back-tabbing
16:51:09 <jugglinmike> Matt_King: This is an example where which tab is active (the tab that is displayed and selected) is manual. You have to press tab or space to activate it. If you make a tab active, then move to another tab, then move out, and then shift-tab backwards
16:51:21 <jugglinmike> Matt_King: I believe the behavior in that case is expected. We should validate that
16:52:02 <jugglinmike> Matt_King: And then for the shift-tab, the wording...
16:52:51 <jugglinmike> Siri: [describes a nuanced shift-tab behavior]
16:53:18 <jugglinmike> Matt_King: I don't know. I'm reading this documentation, and the reporter is having a different interpretation of the documentation
16:53:26 <jugglinmike> Matt_King: I think the behavior and the documentation are aligned
16:53:41 <jugglinmike> Matt_King: I don't think you could skip over the actions button. I suppose you could, but it feels complex
16:54:14 <jugglinmike> Matt_King: There are two options. When you are not in the tab list (your focus is after the tab list) and you're going backwards into the tab list. One option is that the focus could jump directly to the active tab (skipping over the actions button).
16:54:52 <jugglinmike> Matt_King: I think that violates one of our principles: your tab sequence should always be reversible. If you back-tab and then forward-tab, you should end up in the same place from which you first back-tabbed
16:55:04 <jugglinmike> Matt_King: Personally, I hate it when that expectation is violated
16:55:07 <Daniel> q+
16:55:33 <jugglinmike> Matt_King: Essentially having any kind of forks or conditions in the tab sequence, I find that extremely confusing and hard to deal with
16:56:08 <jugglinmike> Matt_King: I can understand why someone might want to skip the actions button when tabbing backwards and only have it when going forward. But in terms of keeping a linear sequence, it doesn't feel like a good idea to me
16:56:39 <jugglinmike> Siri: If you do shift-tab, it is placed on the "more" button, but...
16:56:48 <jugglinmike> Matt_King: It sounds like you might have found a bug
16:57:50 <jugglinmike> Siri: Select any tab, I have "baskin shark" selected
16:57:58 <jugglinmike> Siri: Now tab forward
16:58:08 <jugglinmike> Matt_King: I'm at the "more" button for baskin shark
16:58:16 <jugglinmike> Matt_King: Now, I tab again, and I go to the tab panel for that shark
16:58:28 <jugglinmike> Matt_King: Now if I tab backward, I go back to the same button, and back to the same tab
16:58:34 <jugglinmike> Daniel: I couldn't reproduce what you said, Siri
16:58:39 <jugglinmike> Siri: Maybe I got confused
16:59:23 <jugglinmike> Matt_King: [describes a nuanced tab sequence]
16:59:31 <jugglinmike> Matt_King: That seems to work as expected, as well
17:00:14 <jugglinmike> Daniel: This one's a little bit awkward. I expect it will evolve as aria-actions matures. For now, I think it's the best we can do
17:00:44 <jugglinmike> Matt_King: There is still this kind of debate. For keyboard users who wouldn't be taking advantage of aria-actions, you still have to do something in the tab sequence here... I think
17:01:03 <jugglinmike> Matt_King: This example is suggesting something a little bit different from what, say, Chrome has done in its tab bar
17:01:16 <jugglinmike> Matt_King: I find Chrome's behavior annoying, but I think you could justifiably do it either way
17:01:50 <jugglinmike> Matt_King: As long as it's only one button, I think it's okay. But if you had multiple buttons for tab (which is probably how you would design it if you had multiple aria-actions support)
17:02:11 <jugglinmike> Matt_King: The reason we did it this way for tab-list is because this is the most common application for tab lists. People generally don't put a bunch of buttons for every tab
17:02:39 <jugglinmike> Matt_King: Okay, we're out of time. Thank you very much, everyone, we can wrap it here. I can respond to the issue. It sounds like we are aligned that this is behaving as we expect
17:02:49 <jugglinmike> Daniel: Maybe this deserves an editorial pass to make sure the messaging is clear
17:03:06 <jugglinmike> Matt_King: I think that's a good idea. When you read the documentation, it's kind of complex
17:03:13 <jugglinmike> Zakim, end the meeting
17:03:13 <Zakim> As of this point the attendees have been Daniel, jugglinmike, Siri, CurtBellew, jongund, JoeLamyman
17:03:16 <Zakim> RRSAgent, please draft minutes v2
17:03:17 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/13-aria-apg-minutes.html Zakim
17:03:23 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
17:03:23 <Zakim> Zakim has left #aria-apg