16:01:54 <RRSAgent> RRSAgent has joined #aria-apg
16:01:59 <RRSAgent> logging to https://www.w3.org/2026/06/24-aria-apg-irc
16:01:59 <Zakim> RRSAgent, make logs Public
16:02:00 <Zakim> Meeting: ARIA Authoring Practices Task Force
16:02:09 <Matt_King> present+
16:02:13 <jugglinmike> present+
16:02:18 <Matt_King> CHAIR: att King
16:02:20 <jugglinmike> scribe+ jugglinmike
16:02:27 <jugglinmike> CHAIR: Matt_King
16:02:53 <Matt_King> agenda?
16:03:05 <Matt_King> agenda: https://github.com/w3c/aria-practices/wiki/June-24%2C-2026-Agenda
16:03:07 <agendabot> clear agenda
16:03:07 <agendabot> agenda+ Setup and Review Agenda
16:03:07 <agendabot> agenda+ Publication planning
16:03:07 <agendabot> agenda+ PR 3448: Fix for the link checker
16:03:07 <agendabot> agenda+ PR 3430: Editor Menu Bar Example: Implement optional spacebar behavior for radios and checkboxes
16:03:10 <agendabot> agenda+ PR 3372: Add Experimental Example of Scrollable Listbox with Actions on Options
16:03:13 <agendabot> agenda+ PR 3449: Three Combobox Examples: Expand on click and improve filter behavior
16:03:14 <jugglinmike> present+ Adam
16:03:16 <agendabot> agenda+ Issue 3441: Questions about advanced treegrid practices
16:03:20 <jugglinmike> present+ Daniel
16:03:53 <Daniel> present+
16:05:19 <jugglinmike> Zakim, next item
16:05:19 <Zakim> agendum 1 -- Setup and Review Agenda -- taken up [from agendabot]
16:06:15 <jugglinmike> Matt_King: Any requests for change to agenda?
16:06:32 <jugglinmike> Matt_King: Hearing none, we'll stick with the agenda as planned
16:06:41 <jugglinmike> Matt_King: Next meeting: July 8
16:06:55 <jugglinmike> Zakim, next item
16:06:55 <Zakim> agendum 2 -- Publication planning -- taken up [from agendabot]
16:07:17 <jugglinmike> Matt_King: We currently have three pull requests merged and fully ready to go
16:07:26 <jugglinmike> Matt_King: I think there are two more that may be ready after today's discussion
16:07:40 <jugglinmike> Matt_King: But even if it is to only be the three, then I would like to publish
16:08:08 <jugglinmike> Daniel: That will work. I will be off next week, so I would like to receive a pull request by tomorrow
16:08:14 <jugglinmike> Matt_King: I can try to get it submitted today
16:08:18 <jugglinmike> Daniel: That would be even better
16:08:25 <jugglinmike> Matt_King: Cool. I can commit to that
16:08:39 <jugglinmike> Zakim, next item
16:08:39 <Zakim> agendum 3 -- PR 3448: Fix for the link checker -- taken up [from agendabot]
16:08:51 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3448
16:09:01 <jugglinmike> Matt_King: We were getting 403 errors, and it wasn't clear why
16:09:11 <jugglinmike> Daniel: My systems colleague figured this out
16:10:00 <jugglinmike> Daniel: I suggest we change our approach: instead of trying to mimic a user-agent string, we just use the default
16:10:29 <jugglinmike> Matt_King: Part of me wonders if we get a 403 error, whether we might actually try to use the alternate strategy as well
16:11:12 <jugglinmike> Matt_King: Currently, it seems that all the 403 errors are genuine. I thought we had the University of Illinois one fixed
16:11:22 <jugglinmike> Daniel: Now, it doesn't show 403 errors. It has the link-checker passing
16:11:32 <jugglinmike> Daniel: I last reviewed last week, and it was passing then
16:12:10 <jugglinmike> Daniel: Most of the previous 403 errors were from the W3C, and we got confirmation that old Chrome versions were rejected by the firewall rules
16:12:23 <jugglinmike> Matt_King: Based on the feedback from howard-e, this looks pretty straightforward
16:12:34 <jugglinmike> Matt_King: I think I will merge this today. That doesn't impact the publication plan
16:12:41 <jugglinmike> Zakim, next item
16:12:41 <Zakim> agendum 4 -- PR 3430: Editor Menu Bar Example: Implement optional spacebar behavior for radios and checkboxes -- taken up [from agendabot]
16:12:52 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3430
16:12:58 <jugglinmike> Matt_King: We have had three people look at this
16:13:09 <jugglinmike> Matt_King: It doesn't change anything about visual appearance or design. It's just the keyboard support
16:13:22 <jugglinmike> Matt_King: We had the regression tests changed accordingly, and jongund reviewed that
16:13:29 <jugglinmike> Matt_King: I reviewed functionality in Windows
16:13:42 <jugglinmike> Daniel: And I tested functionality on macOS
16:13:49 <jugglinmike> Matt_King: I think I can merge this today
16:14:03 <jugglinmike> Matt_King: there's one bit of feedback from jongund. It's about a comment in the test file
16:14:20 <jugglinmike> Matt_King: The author didn't respond to that, but it's a one-word change in a comment in a test file, so I will make the change myself
16:14:39 <jugglinmike> Matt_King: It will be included in the upcoming publication. Does anyone have any concerns with that?
16:14:41 <jugglinmike> Adam: Nope
16:14:45 <jugglinmike> Zakim, next item
16:14:45 <Zakim> agendum 5 -- PR 3372: Add Experimental Example of Scrollable Listbox with Actions on Options -- taken up [from agendabot]
16:14:51 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3372
16:15:04 <jugglinmike> Matt_King: We've had a lot of reviews and a lot of flux here
16:15:24 <jugglinmike> Matt_King: I'm a little un-concerned with this not being 100% polished because it is and experimental example and clearly labeled as such
16:15:40 <jugglinmike> Matt_King: There's some outstanding feedback that are kind of just polish
16:15:55 <jugglinmike> Matt_King: The text is written as if selection follows focus, but it doesn't.
16:16:13 <jugglinmike> Matt_King: The functionality is correct; it's the documentation that needs updating
16:16:44 <Daniel> q+
16:16:45 <jugglinmike> Matt_King: Those are pretty trivial editorial changes, so I'm proposing that I make those editorial changes about the automatic selection in the keyboard table. There might also be one small change to the "attributes" table
16:16:58 <jugglinmike> Matt_King: ...and that I raise issues for the other aspects of the review that haven't been addressed yet
16:17:12 <jugglinmike> Matt_King: And that I merge this pull request so that it can inform active discussions in ARIA
16:17:20 <jugglinmike> Matt_King: Are there any concerns about expediting this in that way?
16:17:22 <jugglinmike> ack Daniel
16:17:24 <Adam> q+
16:17:41 <jugglinmike> Daniel: We may get some comments around this. I can't remember if we have other experimental examples already published
16:18:06 <jugglinmike> Matt_King: We do. The only way you can find them is to go to the index and go to the bottom of the page to a section labeled for experimental examples
16:18:13 <jugglinmike> Matt_King: They are not reference from other examples
16:18:32 <jugglinmike> Matt_King: The "experimental" warning is automatically expanded instead of automatically collapsed
16:18:41 <jugglinmike> Matt_King: We have one other experimental example right now
16:19:07 <jugglinmike> Daniel: Just in case, since Remi may not be familiar. But I don't see any issue--this is just a warning that comments may come up
16:19:32 <jugglinmike> Matt_King: I know Shawn was involved in the design to ensure that experimental examples could never be confused with stable examples
16:19:56 <jugglinmike> ack Adam
16:20:17 <jugglinmike> Adam: I'm playing with it now. I'm seeing it resolved an issue that we chatted about. It was where some buttons would be unfocusable.
16:20:30 <jugglinmike> Matt_King: Yes, that is fixed
16:20:55 <jugglinmike> Adam: ...but now, it's making me interrogate the behavior of where we place focus when the thing we would normally place focus on has disappeared
16:21:16 <jugglinmike> Adam: If I move to the "down" button, and I press it, then focus remains on that button, and I can continue pressing it to move things down
16:21:34 <jugglinmike> Adam: When I return to the conditions that we chatted about before, where I'm on the second item from the top, I expected focus to land on the "down" button rather than the item
16:22:14 <jugglinmike> Matt_King: When Curt asked that question, my intuition was to place focus on the item. I thought that would be the most appropriate thing as a screen reader user. I can see the argument for "up" and "down" to go to the opposite item.
16:22:28 <jugglinmike> Matt_King: Delete should always go to the item; not the "delete" button for the next item
16:22:37 <jugglinmike> Matt_King: But if you wanted to keep deleting a bunch of items...
16:23:00 <jugglinmike> Matt_King: This is an important question. I don't know if the input I gave to Curt is really the best, but that is why he did it the way he did
16:23:13 <jugglinmike> Adam: Understood. Honestly, it's quite subjective
16:23:41 <jugglinmike> Adam: As a user, for reordering, I am in a mode of reordering, so I would like focus to remain on something within that task
16:24:12 <jugglinmike> Adam: As for deletion, I agree with your rational that it's too destructive to the next delete button. It could cause users to delete things unintentionally
16:24:32 <jugglinmike> Matt_King: What if we merge it and raise issues for these things and address them in separate pull requests?
16:24:51 <jugglinmike> Adam: That sounds great. I didn't mean to nitpick on minor subjective issues
16:25:36 <jugglinmike> Adam: Also, there's a small bug: when you delete an item, focus lands on the list. It doesn't land on the nearest item.
16:26:05 <jugglinmike> Adam: Probably the next item is the best way of expressing it as a rule. If you're in the middle of the list, then I think people expect that people expect things to sort of "shift up"
16:26:15 <jugglinmike> Matt_King: You're right. The edge case is deleting the final item
16:26:31 <jugglinmike> Adam: This example is so cool, though!
16:27:16 <jugglinmike> Matt_King: Yeah, and it's complete enough to allow us to review and refine the final edge-cases
16:27:45 <jugglinmike> Matt_King: Okay, so I'll merge this, make the editorial changes we talked about, and file follow-up issues for the outstanding comments
16:27:54 <jugglinmike> Zakim, next item
16:27:54 <Zakim> agendum 6 -- PR 3449: Three Combobox Examples: Expand on click and improve filter behavior -- taken up [from agendabot]
16:28:07 <jugglinmike> github: https://github.com/w3c/aria-practices/pull/3449
16:28:26 <jugglinmike> Matt_King: In the previous meeting, we agreed on a set of changes, and the author has already created a pull request for those
16:28:42 <jugglinmike> Matt_King: I haven't reviewed it yet, but it does a lot, so there's quite a bit to review here
16:28:53 <jugglinmike> Matt_King: This is a ways away from being ready for publication
16:29:21 <jugglinmike> Matt_King: There is one open question in the related issue that is not directly related to the pull request that we might want to actually have it captured in the issue--if we decide to discuss it, now
16:29:48 <jugglinmike> Matt_King: But before we go there, is there anyone else that can help me share initial feedback? Not necessarily a formal review, but just early feedback, particularly on their code
16:30:18 <jugglinmike> present+ CurtBellew
16:30:46 <jugglinmike> CurtBellew: I might be able to give light-weight feedback on this
16:30:52 <CurtBellew> CurtBellew has joined #aria-apg
16:31:33 <jugglinmike> subtopic: Issue 3442 question
16:31:40 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/3442
16:32:33 <CurtBellew> present +
16:32:51 <jugglinmike> Matt_King: colm, the contributor, asked the question: is it too aggressive to expand the listbox on first click if you click in the "edit" field of the combobox
16:32:58 <jugglinmike> Matt_King: This is what we discussed in a prior meeting
16:33:11 <jugglinmike> Matt_King: If you click in the combobox and the list is collapsed; that seems like an intent to change the value
16:33:24 <jugglinmike> Matt_King: They agree, they are asking if you should need to click the chevron if you want to see the list
16:34:02 <jugglinmike> Matt_King: This is a pretty subtle UX issue and maybe a matter of there being a lot of different users with a lot of different needs and intents. You try to serve the greatest number in cases like this. And in the most accessible way
16:34:35 <jugglinmike> Matt_King: Our current direction that the pull request takes is that if you click in the input box, we put the focus in the edit box and expand the list
16:34:58 <jugglinmike> Matt_King: The question on the table is: should it do both of those things? Or just put the focus in the "edit" box?
16:35:18 <jugglinmike> s/of the combobox/of the combobox?/
16:36:00 <jugglinmike> Matt_King: I can think of a couple accessibility "pros" for expanding the listbox on click
16:36:15 <jugglinmike> Matt_King: But I don't want to dilute peoples' thinking
16:36:23 <jugglinmike> present+ Jem
16:36:56 <Jem_> Jem_ has joined #aria-apg
16:37:22 <Jem_> present+
16:37:23 <jugglinmike> CurtBellew: To me, I'm sympathetic to the idea that when you click in the field, it doesn't open the dropdown. You're effectively filtering in that case
16:38:04 <jugglinmike> CurtBellew: The only problem is--I like to stick with HTML as much as possible. When you click on a select box in HTML, it opens no matter where you click
16:38:19 <jugglinmike> CurtBellew: I like to follow HTML when possible because that's less surprising to users
16:39:29 <jugglinmike> Matt_King: This pull request changes things. If you have a complete value in the input field, and you trigger any event that causes the drop down to appear, if the value of the combobox is a full value, then you would show the full value of the list
16:39:43 <jugglinmike> Matt_King: The only time it would filter is if you have an incomplete value or no value at all
16:40:10 <jugglinmike> Matt_King: If you type "aj", then you would have an empty list. If you type just "a", then you'd get all the states that start with "a". If you typed "Alaska", you would get all states
16:40:49 <jugglinmike> Matt_King: The way the pull request is currently coded: if the value "alaska" is in the field, an it's not focused, if you click the field, then that will cause the focus to go to the "edit" box and the list will expand
16:41:01 <jugglinmike> CurtBellew: I can't think of a reason why that would subvert users' expectations
16:41:24 <jugglinmike> Matt_King: The contributor expressed surprise about the expansion
16:41:36 <jugglinmike> CurtBellew: I could go either way. I kind of like how the list opens up, especially how you described it
16:42:01 <jugglinmike> Matt_King: From an accessibility standpoint: when it comes to making click targets as easy as possible for users with less control over the mouse, it's nice to have big hit areas
16:42:17 <Adam> q+
16:42:26 <jugglinmike> Matt_King: So clicking the chevron--it seems like it could be helpful to users. Just like you can click the label in radio buttons or checkboxes
16:43:08 <jugglinmike> Matt_King: It's less work for people who want to see the list. If they don't want to see the list, then they can click the chevron... but if you didn't want to see the list, is it a problem that it is there? Is it a problem that it's covering up the content that is below it?
16:43:40 <jugglinmike> Matt_King: That seems like less of a downside if you are just interested in changing the value. But it seems like a larger upside for the folks that would benefit from a larger interactable area
16:43:43 <jugglinmike> CurtBellew: Good point!
16:43:46 <jugglinmike> ack Adam
16:44:01 <jugglinmike> Adam: I agree with all of that. I also agree with CurtBellew's bias toward following native conventions
16:44:22 <jugglinmike> Adam: I'm understanding that there is nothing visually about this control that tells the user that it affords typing. It just resembles a dropdown
16:44:43 <jugglinmike> Adam: It does have a chevron, though, which suggests that it supports choosing an option from a list.
16:45:21 <jugglinmike> Adam: For this pull request, the new implementation satisfies my main concern: clicking again after the listbox was open caused the cursor to vanish. That's gone
16:45:42 <jugglinmike> s/open caused/open previously caused/
16:46:26 <jugglinmike> Matt_King: Thanks. I'm happy to have others weigh in here!
16:46:58 <jugglinmike> zakim, next item
16:46:58 <Zakim> agendum 7 -- Issue 3441: Questions about advanced treegrid practices -- taken up [from agendabot]
16:47:42 <jugglinmike> github: https://github.com/w3c/aria-practices/issues/3441
16:48:49 <jugglinmike> Matt_King: There's a list of things that they are thinking about putting into a user interface. There are four different characteristics that they want. And there's an image
16:49:05 <jugglinmike> Adam: There are two screen captures that include tables with grouped rows
16:49:20 <jugglinmike> Jem_: [reads the contents of the tables in the image]
16:49:43 <jugglinmike> Adam: There's no column for currency
16:49:58 <jugglinmike> Matt_King: But they made groups based on currency?
16:50:01 <jugglinmike> Adam: Exactly
16:50:35 <jugglinmike> Matt_King: Normally, if you have row groups in a table, wouldn't they have to be grouped by a table that's expressed in the table?
16:51:28 <jugglinmike> Matt_King: I'm thinking about other kinds of treegrid examples. When you expand and collapse, that action is based on showing or hiding a group of rows that all fall under a particular node in a hierarchy. They all essentially have a value for that node. But if that node value isn't represented in a column...
16:52:07 <jugglinmike> Jem_: There's one more table: a "cost center" table. [Describes the contents of that table]
16:53:22 <jugglinmike> Adam: I think Matt_King was saying that the information by which rows are grouped needs to be expressed somewhere. It is here, in the form of something that resembles a row but that is actually a column header spanning multiple columns.
16:53:57 <jugglinmike> Matt_King: If the table was expanded and all rows were shown, would it look like a table where you have a column for that attribute? Essentially, where every row in each group would have a value for that column
16:54:18 <jugglinmike> Adam: I've seen tables like that. In these screen captures, though, no. The pieces of information that act as grouping mechanisms don't have their own columns
16:55:02 <jugglinmike> Matt_King: From an ARIA standpoint, that sounds really challenging. From a coding perspective, you would have labeled groups. However, a row group is not a focus-able thing. And it's not a thing where when a screen reader reads a table or a grid--you can't, as far as I know, label a row group in a table
16:55:19 <jugglinmike> Matt_King: THEAD and TBODY, if you labeled them, it doesn't do anything
16:56:07 <jugglinmike> Matt_King: As presented here, there isn't an ARIA convention for creating this kind of thing. Now, if it is a focus-able row in the table... Our treegrid example is the e-mail inbox. It is the subject of the e-mail that creates threads, and there is a column for subject
16:56:31 <jugglinmike> Matt_King: Here, there's no equivalent to the subject column, right?
16:56:31 <jugglinmike> Adam: Correct
16:56:42 <CurtBellew> https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/examples/treegrid-1/
16:56:57 <jugglinmike> Adam: There is no column, so it is not comparable to this.
16:57:08 <jugglinmike> Adam: In our case, the only value for "subject" is "treegrids are awesome"
16:57:23 <jugglinmike> Matt_King: Yeah, it's a very simple treegrid there. If it were a real inbox, you would have more than one thread
16:57:47 <jugglinmike> Adam: Their equivalent is that they would have two treegrids nested that happen to have the exact same structure. The same columns, but they would have a group heading
16:58:01 <jugglinmike> Matt_King: But essentially they would have to be separate treegrids where you would tab from one to the next
16:58:14 <jugglinmike> Matt_King: That sounds awful but not impossible
16:59:01 <jugglinmike> Matt_King: You could use the "down arrow" to go from tree grid to tree grid. It would have to be a totally custom thing. Technically in ARIA, you would have to make the separate treegrids. I don't think you can nest treegrids
16:59:33 <jugglinmike> Matt_King: From an API point of view, if it was a series of treegrids, you could have custom documentation for moving from one grid to the next grid. It might be a little bit complicated, though
16:59:59 <jugglinmike> Matt_King: I'll re-read the issue and try to summarize our discussion
17:00:22 <Jem_> thanks for the scribe, Mike!
17:02:07 <Jem_> I saw similar table pattern from the state governement medicare data.
17:02:23 <jugglinmike> Zakim, end the meeting
17:02:23 <Zakim> As of this point the attendees have been Matt_King, jugglinmike, Adam, Daniel, CurtBellew, Jem, Jem_
17:02:26 <Zakim> RRSAgent, please draft minutes v2
17:02:27 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/24-aria-apg-minutes.html Zakim
17:02:35 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
17:02:35 <Zakim> Zakim has left #aria-apg