15:57:05 <RRSAgent> RRSAgent has joined #aria-apg
15:57:09 <RRSAgent> logging to https://www.w3.org/2026/04/15-aria-apg-irc
15:57:09 <Zakim> RRSAgent, make logs Public
15:57:10 <Zakim> Meeting: ARIA Authoring Practices Task Force
16:02:27 <jugglinmike> jugglinmike has joined #aria-apg
16:02:45 <Jem_> Jem_ has joined #aria-apg
16:03:17 <Jem_> rrsagent, make minutes
16:03:18 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/15-aria-apg-minutes.html Jem_
16:03:48 <Adam> present+
16:04:39 <Daniel> present+
16:04:40 <Jem_> https://github.com/w3c/aria-practices/wiki/April-15%2C-2026-Agenda
16:04:49 <Jem_> present+ jem
16:04:54 <jugglinmike> present+ jugglinmike
16:04:57 <Jem_> present+ jongund
16:05:00 <jugglinmike> scribe+ jugglinmike
16:05:22 <jugglinmike> Topic: Setup and Review Agenda
16:05:32 <jugglinmike> Jem_: Any requests for change to agenda?
16:05:36 <jugglinmike> https://github.com/w3c/aria-practices/wiki/April-15%2C-2026-Agenda
16:05:45 <jugglinmike> Jem_: Next meeting: April 29
16:05:59 <jugglinmike> Jem_: Hearing no requests, we'll stick with the agenda as planned
16:06:22 <jugglinmike> Topic: Publication planning
16:06:35 <Jem_> https://github.com/w3c/aria-practices/milestone/41
16:06:35 <jugglinmike> Jem_: This is tracked with Milestone #41
16:07:22 <jugglinmike> subtopic: PR 2991: Add Practice Page for Supporting Color Contrast Settings by mcking65
16:07:29 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/2991
16:07:40 <jugglinmike> Matt_King: We had a review from Joe, who suggested some changes
16:07:46 <jugglinmike> Matt_King: And this morning, jongund pushed a commit
16:08:03 <jugglinmike> jongund: Yeah, I've been re-organizing the heading structure based on those suggestions
16:08:16 <jugglinmike> jongund: I'm going to work on updating some of the content, too. We've been missing a section for testing
16:08:22 <jugglinmike> jongund: So this is in-progress
16:08:40 <jugglinmike> jongund: I'll send an e-mail to the list when this is ready
16:08:52 <jugglinmike> Matt_King: Sounds like good progress! Thank you!
16:09:15 <jugglinmike> subtopic: PR 3387: Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls” by adampage
16:09:20 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3387
16:09:36 <jugglinmike> Matt_King: This turned out to be not so simple! Small, but not simple
16:09:41 <jugglinmike> Matt_King: I made two small suggestions
16:10:01 <jugglinmike> Adam: And I made commits this morning to accept those changes and to merge in master
16:10:37 <jugglinmike> Adam: Merging in the main development branch didn't address the problem, though. The linter continues to complain about a link that is returning a 403 error
16:10:45 <jugglinmike> s/master/the main development branch/
16:11:12 <jugglinmike> Adam: The links are to a Firefox plugin that I believe jongund wrote
16:11:35 <jugglinmike> jongund: Ah, there's a better URL for that project. It's to a more stable page that I control
16:11:44 <jugglinmike> Matt_King: Could you file a new pull request for that?
16:12:01 <jugglinmike> jongund: Sure; which page is this on?
16:12:18 <jugglinmike> Adam: I've just now tagged you on the comment that describes the issue
16:12:41 <jugglinmike> Matt_King: So this one is ready to merge. Daniel can you take a look and let us know if we're aligned?
16:12:59 <jugglinmike> Daniel: I reviewed quickly already, so I think this is fine. I'll leave a comment
16:13:07 <jugglinmike> subtopic: PR 3400: Revise Content for New Experimental Example of Scrollable Listbox with Actions on Options by mcking65
16:13:13 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3400
16:13:27 <jugglinmike> Matt_King: I think we'll skip this for now because Curt isn't present today
16:13:37 <jugglinmike> subtopic: PR 3418: Landmark Practice: Update alignment between HTML aside element and ARIA complementary role by NakajimaTakuya
16:13:43 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3418
16:14:09 <jugglinmike> Matt_King: The last time we discussed this, jongund had review it, but he hadn't actually looked at whether or not the content changes were aligned with the HTML-AAM.
16:14:25 <jugglinmike> Matt_King: Last time we talked about this, we talked about some potential bugs in Firefox--but that isn't relevant to the pull request
16:14:46 <jugglinmike> Matt_King: What's relevant is whether the text correctly reflects the HTML-AAM, so I think this still needs your review, jongund
16:14:59 <jugglinmike> Jem_: Joe is also marked as a reviewer, so we should nudge Joe
16:15:07 <jugglinmike> Matt_King: Daniel is also listed as a reviewer
16:15:32 <jugglinmike> Daniel: Ah, yes, now I remember. On the WAI website, we have an implementation that just uses summary and details that operates like an accordion
16:15:38 <jugglinmike> Matt_King: That was a different issue, actually.
16:16:14 <jugglinmike> Matt_King: This issue is related to the "aside" element and how our guidance doesn't currently reflect recent changes to the AAM. The author has proposed change that he believes will align our guidance
16:16:32 <jugglinmike> Daniel: I have been speaking with Valerie to add this to the ARIA group's agenda on Thursday
16:16:39 <jugglinmike> Matt_King: Okay, thanks for doing that. That's good
16:16:51 <jugglinmike> subtopic: PR 3421: AlertDialog Pattern: Add guidance about use of `aria-modal` attribute by NakajimaTakuya
16:16:56 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3421
16:17:17 <jugglinmike> Matt_King: I've done a review on this, so before I we talk about this, we should give Joe a chance to review
16:17:33 <jugglinmike> Subtopic: skipTo.js update
16:18:06 <jugglinmike> jongund: There is no pull request for this, yet, but I'm currently fielding a request to make the link visible on mobile
16:18:25 <jugglinmike> Matt_King: That's interesting. You might want to propose the change and then have people review that.
16:18:41 <jugglinmike> jongund: Alright!
16:18:58 <jugglinmike> topic: PR 3434: Accordion Pattern: Remove optional arrow, home, and end keys
16:19:04 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3434
16:19:14 <jugglinmike> Matt_King: This originates from our discussion from the previous meeting on April 31
16:19:20 <jugglinmike> s/April/March/
16:20:06 <jugglinmike> Matt_King: This also has one very minor editorial change. It's not part of the issue, but I decided to include it because it's so minor
16:20:20 <jugglinmike> Matt_King: I think given the size of this change, just one reviewer should be adequate
16:20:22 <jugglinmike> jongund: I can review
16:20:27 <jugglinmike> Matt_King: Okay, I will assign you
16:20:39 <jugglinmike> Matt_King: I've added this to the publication plan for May, so that's the time-frame we're on
16:20:58 <jugglinmike> Matt_King: Thank you, jongund
16:21:40 <jugglinmike> topic: Issue 2438: Tablist that supports reflow
16:21:48 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/2438#issuecomment-4041766532
16:22:33 <jugglinmike> Matt_King: This is on the agenda because there is someone commenting that they're trying to work on tabs for a design system, and they want to make sure that their "tabs" component supports reflow
16:22:58 <jugglinmike> Matt_King: The questions that they are asking in recent comments are from March 11 (I wish we had this on our previous agenda)
16:23:49 <jugglinmike> Matt_King: We made sort of what I'll call a "high-level" or "not very concrete" proposal for a solution in this issue. One that suggests that there could be a menu button that allow people to open a menu where they could choose from additional tabs that could be displayed
16:24:06 <jugglinmike> Matt_King: So if you only have room to display, say, three tabs, then you could use the menu button to choose which tab is the third tab
16:24:45 <Adam> q+ to mention https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-actions/
16:24:54 <jugglinmike> Matt_King: There are a lot of questions about how this should work. I think there are both design questions (which the APG does not need to be opinionated about) and accessibility question (where the APG should offer some guidance)
16:25:20 <jugglinmike> Matt_King: I think we have learned from experience that whenever there are tricky questions like this, the only way we end up with real answers is to attempt to do it ourselves
16:25:32 <jugglinmike> Jem_: Yes. Creating an example raises so many important questions
16:25:40 <jugglinmike> ack Adam
16:25:40 <Zakim> Adam, you wanted to mention https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-actions/
16:26:09 <jugglinmike> Adam: The aria-actions example I made a while back does support reflow. It's not the most elegant solution (it just stacks the tabs), but it conforms
16:27:05 <jugglinmike> Adam: When I began developing that aria-actions example, I started with the tablist as an example, but I noticed that they don't support reflow, so I added support for that
16:27:28 <jugglinmike> Adam: The tabs become vertically stacked. They really just reflow like any other inline element. The tabs themselves wrap
16:27:49 <jugglinmike> Matt_King: What happens to the tabs on the second line if you have a tab on the first line selceted?
16:28:30 <jugglinmike> Adam: That case is not elegant because the visual link between the tab and the content is broken, but the state is still apparent due to the other visual properties
16:28:49 <jugglinmike> Matt_King: That is one approach, and maybe we should modify the simpler "tabs" examples to do that
16:29:08 <jugglinmike> Matt_King: However, I do think there is another common pattern out there that is "prettier" but slightly more complex from the accessibility point of view
16:29:22 <jugglinmike> Matt_King: I think the thing that's always held us back is that you can't place a button in a tab list
16:29:45 <jugglinmike> Matt_King: But if we had the tablist element reference it... I don't know how legitimate that would be, though
16:29:47 <Jem_> This design is common Example 1 – Fluent UI: Tablist with Overflow
16:29:47 <Jem_> https://storybooks.fluentui.dev/react/?path=/docs/components-tablist--docs#with-overflow
16:30:07 <jugglinmike> Adam: We don't strictly need aria-actions to address this
16:30:18 <jugglinmike> Matt_King: The commenter describes adding a menu button that acts like a tab
16:30:29 <jugglinmike> Matt_King: It's not a great experience because it's called a tab but it's not a tab
16:30:42 <jugglinmike> Matt_King: Others just put a menu button in the tab list, but that fails conformance checkers
16:31:14 <jugglinmike> Matt_King: There's a "Trick" for this [describes trick]
16:31:37 <jugglinmike> Adam: Oof, I don't know if we want to describe a solution that we wouldn't recommend in the real world...
16:31:51 <jugglinmike> Adam: We could do something at the edges to show the availability of additional options
16:31:54 <CurtBellew> CurtBellew has joined #aria-apg
16:31:57 <jugglinmike> Matt_King: A tiny bit like a carousel
16:32:00 <CurtBellew> present+
16:32:01 <jugglinmike> Adam: Exactly
16:32:27 <jugglinmike> jongund: We have to consider what they are building. They are building a tab where the things are in a list. We should have an example that demonstrates that because that's what people are doing
16:32:39 <jugglinmike> Matt_King: The only problem is that ARIA doesn't give you a way to make that
16:32:57 <jugglinmike> jongund: But it's just styling. I don't see any change to the code other than CSS styling
16:33:04 <jugglinmike> Matt_King: Maybe I don't understand what you're suggesting, then
16:33:34 <jugglinmike> jongund: In the example the commenter is pointing to, they make the horizontal tab vertical. Instead of hilighting beneath the tab, they hilight to the left of the tab.
16:33:43 <jugglinmike> jongund: My guess is that is a pretty common thing that people do
16:34:02 <jugglinmike> jongund: We should have an example that demonstrates that. Maybe one that changes from a vertical list to a horizontal list
16:34:19 <jugglinmike> Matt_King: I understand, now. Would you change the arrow key binding, as well?
16:34:30 <jugglinmike> Matt_King: And change aria-orientation?
16:34:36 <jugglinmike> jongund: Is it valid on a tab list?
16:34:40 <jugglinmike> Matt_King: Yes
16:34:45 <jugglinmike> jongund: then we should add that
16:34:55 <jugglinmike> Matt_King: We have notes about the keyboard interaction in the pattern, as well
16:35:19 <jugglinmike> Jem_: I know the use case. You have so many tabs, and there is no affordance that you have ten tabs. That's why people have a "More..." tab
16:35:39 <jugglinmike> Jem_: In Adam's example, he can have 10 tabs, and he can stack them across the viewport
16:35:55 <jugglinmike> jongund: In the example here, they have a button to reveal the additional tabs
16:36:32 <jugglinmike> Matt_King: We have four approaches: the crude wrapping approach (which Adam implemented), the horizontal scrolling (as Adam suggested), the switch to vertical, and the "more..." button (which is technically most complex)
16:36:50 <jugglinmike> jongund: Do we have to have a "more" button? Do the users have to know that there's more available?
16:37:04 <jugglinmike> Matt_King: Yeah, you have to make your touch and your keyboard aligned with one another
16:37:12 <jugglinmike> jongund: How would that affect touch?
16:37:33 <jugglinmike> Matt_King: If you're scrolling through your tabs with touch, you would have to double-tap the "More..." link to access the additional tabs
16:37:54 <jugglinmike> Matt_King: That corresponds to an additional interaction. It would be really confusing if you had to do it one way with touch and another way with keyboard
16:38:04 <jugglinmike> Matt_King: On mobile, I switch between touch and keyboard all the time
16:38:16 <jugglinmike> Matt_King: Okay, so there are there these four approaches
16:38:35 <jugglinmike> Matt_King: We have two simple tab examples now: one with automatic selection and one with manual selection
16:38:54 <jugglinmike> Matt_King: We could demonstrate horizontal scrolling and vertical scrolling very easily by choosing to do one example with one and the other with with other
16:39:06 <jugglinmike> Matt_King: Adam is saying that it's not realistic to use aria-actions for this
16:39:21 <jugglinmike> Adam: Well, people have done it in real life. It's not terrible, but it's not great, either
16:39:40 <jugglinmike> Matt_King: Maybe it's something for the future, then
16:39:59 <jugglinmike> jongund: When you choose one of the items in the pop-up menu, it changes the ones that are visible. The final one becomes the selected on
16:40:05 <jugglinmike> s/selected on/selected one/
16:40:11 <jugglinmike> Matt_King: Right, that's common
16:40:23 <jugglinmike> Matt_King: I'm just saying there are some really thorny questions with the "More..." button approach
16:40:56 <jugglinmike> Matt_King: For instance, when it comes to the placement of the button, especially considering conformance with ARIA
16:41:40 <jugglinmike> Matt_King: I just think the ARIA spec doesn't address the "More..." button approach. That makes it difficult to discuss in the APG, so I think we need to file an issue with ARIA as a start
16:42:05 <jugglinmike> Adam: That's why I like the simple reflow approach because it satisfies the specs
16:42:14 <jugglinmike> jongund: Will anyone use it in the real world, though?
16:42:20 <jugglinmike> Adam: Yes, people use it all the time
16:42:37 <jugglinmike> Matt_King: I think it would be a good thing to demonstrate that in our examples
16:43:08 <jugglinmike> Matt_King: Is there an advantage for mouse button users? Is it hard to scroll those?
16:43:27 <jugglinmike> jongund: what about the toolbar pattern? Does it change to a toolbar if you do what they're talking about here?
16:43:54 <jugglinmike> Matt_King: Well, you can't place tabs in a toolbar?
16:43:54 <jugglinmike> jongund: Right, but maybe the tabs are now a list of disclosure buttons
16:44:01 <jugglinmike> Matt_King: I don't think that would fly in the real world. I don't see people changing their tablists to toolbars
16:44:53 <jugglinmike> CurtBellew: At Oracle, we have three of these implementations. Or at least two of them. One is the "scrolling list". For AT users, you go through each, and it feels like a long list. For a visual user, it fits in a frame, and you have a button you can click that will cycling through the options.
16:45:22 <jugglinmike> Adam: My suggestion also includes visual buttons to assist the scrolling (rather than just presenting a scrollable area)
16:45:27 <jugglinmike> CurtBellew: Right, ours too, actually
16:45:45 <jugglinmike> Matt_King: The keyboard user doesn't use them, so they wouldn't be in the tab order. Does the touch user need them, though?
16:46:19 <jugglinmike> Adam: Yes, and that makes this solution a double-edges sword. It can be inconsistent for different users. That's why I've generally avoided explicit scroll assistant buttons
16:46:51 <jugglinmike> CurtBellew: I think for our implementation, they check if it's mobile, then they don't show the buttons (users can only swipe to reveal more items)
16:47:24 <jugglinmike> Adam: I've seen bad implementations where there is no indication that the tabs can scroll. If the tabs are arranged "just so" it's easy to be tricked into thinking that there are actually no additional tabs at all
16:48:51 <jugglinmike> Matt_King: I guess the availability of scrolling "helper" buttons is a complicated thing from an accessibility point of view. That would be a reason for APG to illustrate it. But then again, a reason NOT to illustrate it is if we believe it is unrealistic or overcomplicated
16:49:03 <jugglinmike> Adam: I'd vote "no" for the scroller buttons
16:49:21 <jugglinmike> Matt_King: It sounds like we should do both. The number of options here is growing...
16:49:39 <jugglinmike> Matt_King: Maybe we should just focus on the horizontal scrolling and have one that has the buttons and one that does not. Then people can compare that
16:49:57 <jugglinmike> Matt_King: ...and then LATER, we can consider adding further examples that contemplate switching to vertical layouts
16:50:39 <jugglinmike> Matt_King: We could have two people work on this. I think that would be cool because it could inspire different ideas. Someone on the "automatic activation" could do without the scroller button. And then the one on the "manual activation" could include the scroller buttons
16:50:41 <jugglinmike> Adam: I like that
16:50:48 <jugglinmike> Matt_King: That could be two separate pull requests
16:52:36 <Jem_> Mike: Fifth examplae - a fading pardigm
16:52:52 <jugglinmike> Matt_King: I was assuming that scrolling without helper buttons would do that.
16:52:59 <jugglinmike> Matt_King: But it sounds like I shouldn't have assumed that
16:53:22 <jugglinmike> Adam: Big "plus one" to jugglinmike's suggestion. We either use a "fade" effect or a "drop shadow" which also indicates overflow
16:53:32 <jugglinmike> Matt_King: Is either better in terms of supporting high-contrast
16:53:44 <jugglinmike> Adam: Ooh, wow. I don't know if I've considered high-contrast in this context
16:54:09 <jugglinmike> Adam: Both of those effects would probably break in high-contrast, honestly. They'd both be wiped out in high-contrast mode...
16:54:16 <jugglinmike> Matt_King: Okay, that's a pretty interesting question
16:54:38 <CurtBellew> I need to drop off to attend an urgent call.  If you all have a chance please take a look at current demo changes in https://github.com/w3c/aria-practices/pull/3400
16:54:40 <Jem_> Mile:..indicate taht there are additional options without actually presenting interactable UI is to use.
16:54:45 <jugglinmike> Adam: My hot-take would be to say, "well, there's a scrolling region, so just display the scroll bar". It's an existing UI paradigm for visualizing scroll-ability
16:55:30 <jugglinmike> Adam: perhaps you could be clever by not rendering the scroll bar outside of high-contrast mode (and just relying on the fading/drop-shadow paradigms, instead)
16:55:44 <jugglinmike> Adam: this is right up my alley, but I am so busy right now that I can't take it on
16:56:01 <jugglinmike> Matt_King: James N might be a good candidate for this work
16:56:27 <jugglinmike> Matt_King: We can use this discussion to create some highly specific requests, and then those could be more approachable by anybody outside of this room
16:56:34 <jugglinmike> Adam: I agree. They smell like "good first issues" to me
16:57:00 <jugglinmike> Matt_King: We could create two issues from this issue and make this issue dependent on resolving those two new ones.
16:57:21 <jugglinmike> Matt_King: Maybe that's the approach to take for now. Maybe even the person who asked the question on March 11 would be interested in helping out
16:57:43 <jugglinmike> Adam: Yeah. I also wonder if Ari would be interested. This seems like it's in her wheelhouse, if she's available of course
16:58:26 <jugglinmike> Zakim, end the meeting
16:58:26 <Zakim> As of this point the attendees have been Adam, Daniel, jem, jugglinmike, jongund, CurtBellew
16:58:29 <Zakim> RRSAgent, please draft minutes v2
16:58:30 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/15-aria-apg-minutes.html Zakim
16:58:36 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
16:58:36 <Zakim> Zakim has left #aria-apg
16:58:41 <jugglinmike> RRSAgent, leave
16:58:41 <RRSAgent> I see no action items