Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: Next meeting: January 9, 2024
Status of Site Updates
howard-e: Shawn reported a build error during the deploy today. It doesn't seem related to APG itself, but we're actively investigating
howard-e: In the mean time, we shouldn't expect any of the changes from the agenda in the production site
howard-e: Alex_Flennikan and I are assisting Shawn today
Matt_King: If we can't resolve this, then we'll be waiting until January. I've been careful to let folks know that a deployment might not happen until 2024, but in any case, good luck!
Matt_King: I wonder if there's a better way to broadcast changes
Matt_King: We recently changed some guidance that's been in place for over five years
Matt_King: I wonder if I should write up a "year in review" for the W3C blog
dmontalvo: I think that could work
<Jem> +1 to blog post idea to share the updates
Matt_King: We got a response to the feedback on naming. I was really happy to see engagement from Patrick on that
Jem: I also support sharing an update via a blog post (wherever we might publish it)
Possible select-only combobox bugs
[Select-Only Combobox] Clicking the label behaviour · Issue #2859 · w3c/aria-practices
github: w3c/
Matt_King: This is something I can't test
jugglinmike: I can reproduce the reported bug
Matt_King: Then I'll label the GitHub issue as a bug
jongund: I can work on a fix
BUG Android+Talkback with simple combobox · Issue #2855 · w3c/aria-practices
github: w3c/
Jem: I have an Android device that I can use to verify this report
Matt_King: Then we'll assign it to you for triage purposes. If you can verify it, then you can add a "bug" label, and we'll meet again to assign someone for a fix
Jem: Sounds good
Listbox naming guidance
github: w3c/
Matt_King: Listbox *does* require a name in ARIA, but in a composite like a combobox, we don't require a name on the element itself.
Matt_King: I think this is in part an ARIA question, not just an APG question
jamesn: I believe there's already an issue for this
jamesn: Maybe I'm misremembering, though
Jem: Should we transfer this to ARIA, then?
Matt_King: We might need a separate issue for ARIA
Matt_King: We got some feedback on this issue, but that was back in the 1.1 combobox days when these things were separate
jamesn: Is it easiest to recommend a name on the listbox in this case, even though it's redundant?
<jamesn> previous issue was w3c/
Matt_King: I'll take this issue
Matt_King: I'm going to label this as an inaccuracy; I believe this is all editorial
Jem: this is related to issue 2290
Tab and Shift+Tab in treegrid
github: w3c/
Matt_King: I'm kind of unclear about the inconsistency that has cropped up in treegrid where tab sometimes stays in the grid and other times it does not
Matt_King: I'm not really sure what we should do here because we have inconsistencies in what we do between grid and treegrid
Matt_King: I know there have been a variety of approaches in different implementations
Matt_King: There's a suggestion in tree grid that tab doesn't have just one tab stop in the grid but stops in every cell in the focused row
jamesn: Yes, though sometimes that behavior only occurs following an action on a specific row
jamesn: Subtle differences in the way these implementations work can make it tough to specify a single solution here
Matt_King: So should the focus go to the row or should it go out of the grid?
Jem: I thought that the focus should go out of the row
jamesn: I think it should go to the row
jamesn: the desired behavior appears to be implemented in the APG's example, so I think this is strictly an editorial problem
Matt_King: I'm labeling this as "editorial"
jamesn: Focus isn't reversible when you tab out of the treegrid and go back. Focus goes to the row--it doesn't go to the final cell in the row
jamesn: I'm actually okay with that non-reversible behavior because (due to the way the web platform works) implementing the reversible behavior would be a significant burden on authors
Matt_King: I can see it either way. That said, it's not directly related to the issue we're discussing right now
Matt_King: I will fix it
Escape in disclosure nav menu
github: w3c/
Matt_King: Escape is all optional
Matt_King: I don't like the way we use the word "Dropdown" here. It doesn't seem like the right word in a disclosure because it sort of implies a menu
Matt_King: Why do we close these on blur in the disclosure? That doesn't seem right
Matt_King: Going back to our previous discussion, if you tab out, you should be able to tab back to where you were
Matt_King: This is not a menu, so tabbing is not expected to close. If you have a link, for example, and you tab away from that link, you should be able to tab back to that link. I'd be shocked if I couldn't do that
CoryJoseph: What the reporter is describing doesn't seem like a bug according to the definition of Disclosure Menu
jugglinmike: I wonder if there's a parallel with mouse users. If I hover out of the dropdown, it remains open. To the extent that the position of my cursor describes my "focus" as a mouse user, then the "close on blur" behavior seems inconsistent for keyboard users
jongund: It seems like when one menu opens, it should close the other menus. One reason people use menus is to reduce visual clutter
Matt_King: That seems reasonable to me, but you have to take an explicit action to expand the other menu
Matt_King: The issue that was reported appears to be editorial, but I'm having trouble understanding as written
Matt_King: I'll ask for clarification
Matt_King: There's also a potential bug here which might be a separate issue, but we'll see about that after we receive clarification