Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for changes?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: June 10
Matt_King: Publication planning
Publication planning
Matt_King: We published four updates last week! Hooray!
Matt_King: We have some other things that are close but which didn't make it
Matt_King: There are six pull requests in the new milestone. I set a new milestone for that
Matt_King: One of those six is already merged, so there are five open pull requests remaining
Matt_King: Three of those five are on today's agenda, and the other two are pretty light
Matt_King: I set a target date of June 25th for this milestone. That's the last full week of June; I just wanted to do this before July
Daniel: I think that will work. I don't expect holidays or breaks until July at the earliest
Matt_King: I encourage people to review the milestone. If you feel that something is missing, please bring it up--comment in the pull request
PR 3445: Editorial change to Experimental Tabs with Actions Example
github: w3c/
Matt_King: This is a change to the experimental tabs
Matt_King: It was complicated to word, but it's in response to an issue we discussed in our prior meeting, two weeks ago
Matt_King: Adam, I know you worked on this example and that you may have written the original wording that was confusing the person who shared feedback
Adam: I did indeed write that language. I'd be glad to review your revision
Matt_King: This is just editorial, so I don't think we need more than one additional reviewer (though I have asked the issue reporter to take a look, as well)
PR 3430: Editor Menu Bar Example: Implement optional spacebar behavior for radios and checkboxes
github: w3c/
Matt_King: This was raised a little while ago. I did the initial review
Matt_King: This comes from a person who was a first-time contributor at the time
Matt_King: It's about adding some of the optional keyboard behavior in the menu bar. They were documented but not implemented in the example
Matt_King: I did an initial review, I asked them to make some changes, and they made those changes. Now, I think it's ready for more thorough review from others: code, tests, editorial
Matt_King: I think we should have at least two other people looking at this
Matt_King: This seems to be reasonably well-documented
Daniel: I'd like to review this one
Matt_King: Thank you, Daniel!
Matt_King: Does anyone here have bandwidth to review the changes to the regression tests?
Daniel: The link checker is throwing an error. It's trying to fetch some GitHub links, encountering a rate limit, and assuming that there is no data on those pages.
Matt_King: I wonder why the response would be so slow. As I recall, we gave it a decent amount of time. Well, it's something to look into. It doesn't necessarily block this pull request, though
Matt_King: It's showing up on a whole bunch of pull requests
Daniel: Yes
PR 3372: Add Experimental Example of Scrollable Listbox with Actions on Options
github: w3c/
Matt_King: This is CurtBellew's fabulous work
Matt_King: I've merged all the changes that we were making into a separate branch and somehow broke the preview. Thanks to howard-e's great documentation, though, I was able to recover the preview
Matt_King: Strangely, it seemed like pull request comments had been inserted into the example code. But I fixed all that
Matt_King: I think there are three things to talk about here
Matt_King: First, there is an issue related to the tab behavior that we discussed two weeks ago, CurtBellew. I didn't see a commit to repair that
CurtBellew: It's a kind of simple fix. I did it yesterday, but I didn't push it before you did your work. I can replicate it fairly quickly today
Matt_King: Okay
Matt_King: Second, the CSS and JS linters are both throwing errors
CurtBellew: I haven't seen them. I can take a look
Matt_King: I didn't auto-repair them because I thought it would be better for you to review
Matt_King: Third pertains to live regions. Currently, there is labeling content that reads "last update colon"
Matt_King: It's currently the very first thing in the screen reader reading order in the example. It's a confusing string to hear before the content following the colon is populated
Matt_King: It would be ideal if there is no residual content in the DOM from the live regions because they don't add any value before they are announced
Matt_King: I commented to suggest moving that to the end of the example. And possibly change it from "last update" to "notification" so its purpose is more clear
Matt_King: But I've been thinking about two alternatives that might be better
Matt_King: First, to remove the string and just populate the region dynamically and remove the element from the DOM completely after 15 seconds or so
Matt_King: Or we could use the new aria-notification API because I believe there are at least two browsers with support. There might be more
Adam: As far as I know, it's just Chromium and Mozilla. I know WebKit is working on it, but they've at least announced it
Matt_King: This is an experimental example, after all, so there's part of me that wants to give it a try
Adam: I'd say to do it with graceful degredation. You can do a feature check, and fall back to a live region.
Adam: The live region would have to be present in the DOM in that case, making it kind of a reverse-reverse fallback.
Matt_King: You can inject live regions
CurtBellew: It could remain empty
Adam: True, but for hygiene, I'd be tempted to remove it
Matt_King: If there is a div element that is empty but live, and you just inject the content--from everybody's point of view, it's empty until it has content. That should get announced, right?
Adam: Definitely. I think of that as the default use case
Matt_King: Is there any problem with just removing that text after a delay?
Adam: I don't think so. In fact, that's exactly what I do in the APG spin button example
CurtBellew: It's generally our policy, too, to let content in the live-region sit for a time and then remove it
CurtBellew: I can look into doing the feature detection and implementing both approaches
Matt_King: For expediency, you might want to just move it to the end and put the content on a timer. Then, if you want to get ambitious, you could explore that more advanced solution
Matt_King: Like I said, this is an experimental example, and it's going to remain experimental until aria-actions is in the spec, and I don't know how long that's going to be
Matt_King: Okay, actually, there's a fourth thing to discuss
Matt_King: I thought we had a read-only edit field that you can tab to
CurtBellew: It's not in the tab order. It's just a div element under the details heading
Matt_King: I don't see the content showing up with JAWS
Matt_King: I think it would be much better if it was a read-only edit that you could tab to. Something that's focus-able
CurtBellew: Okay
Matt_King: That's everything that I had for this pull request. Does anyone else have anything?
Matt_King: Hearing nothing, I think we're really close to merging this into main!
Daniel: As per when aria-notify is going to be in the spec. I'm pushing for the publication of a working draft as soon as possible. If all goes well, we should have a recommendation published by the end of the year
Matt_King: Okay. aria-actions is sort of behind, though
Daniel: Yes, that's right. aria-actions isn't ready, yet
Adam: I think I discovered a bug in the implementation
Adam: After I move the top item down, the "move up" item is not focus-able
Adam: On a fresh load, go to "complete and iron man", use your arrow keys to get to the "down arrow" item, activate it, and then try to navigate to the "up arrow"
Matt_King: Also, I think there should always be a selected item, even on initial load, so there are always details showing
CurtBellew: I'll take a look!
Matt_King: Thank you for all your work on this, CurtBellew! I think this is a really important example, and it will be nice to have a really robust discussion of the example. It will demonstrate all the considerations behind aria-actions. We really need it to move aria-actions forward.
Issue 3442: Guidance for the combobox - input click behavior
github: w3c/
Matt_King: This is a well-written issue. The reporter has a question and has done a lot of research comparing different implementations of combo box
Matt_King: Would we consider this an accessibility question?
Matt_King: APG does not give any guidance on mouse behavior. It just implements what is typically considered acceptable behavior, but we do not write anything at all about how the pointer should behave (except when it comes to very specific accessibility issues, like how keyboard and mouse interaction intersect with one another for hover-based interactions)
Matt_King: One option is for the Task Force to hold no particular opinion on this
Matt_King: But if this is somehow related to accessibility, then I'm definitely open to that perspective
Matt_King: The only accessibility issue that I'm thinking of is the suggestion that the mouse user would have an option that isn't available to keyboard users.
Matt_King: If the combo box already has a value in it, and you click it, should it just receive focus, or should it show the entire list, or should it show a subset of the list based on what the current value is?
Matt_King: ...except I don't know how you would show a value based on a subset because a subset would just be that one item since it's a complete value.
CurtBellew: I think I follow the question. Are we asking, "If there are values pre-populated in the combo-box, should it open when you click on it or not?"
Matt_King: The scenario that they shared: you open the menu, you type some characters and choose a filtered option. You choose a value, it says "option is picked", and then you click on the menu again. I think that means click on the combo box... Or maybe click on the chevron
Matt_King: We have a down-arrow or chevron next to the combo box in all of these, right?
CurtBellew: In the example without auto-complete, clicking in either place opens the drop-down and shows the entire list
CurtBellew: The editable combo box with grid, though, it doesn't have a chevron. When you click in it, you have to start typing to see the filtered list
Matt_King: You're right, the link to aria examples points to the example without auto-complete
<Jem_> https://
CurtBellew: It looks to me like there are two kinds of examples. The one without a chevron does not open when you start typing
Matt_King: If you have a value and click on the chevron, does it have the entire list?
CurtBellew: I have to check
Adam: I think the author of the issue may have unintentionally referenced the wrong example
Adam: In their implementation, they have built a kind of type-ahead. It appears to be working with a substring match
Adam: I'm trying to hone in on one aspect that I think the reported means to emphasize. When I mouse-click on the input, and it opens the menu, that's fine. The input is still empty, and it's presenting a list of potential filtering options. When I click again, it closes that menu. In the reporter's list of examples, they all vary on that second interaction
Adam: Some of those examples close and some don't. The reporter may think it's disorienting to close the menu on click unnecessarily
Adam: In APG's combo box with autocomplete, if I click once on the empty input, it expands the input. If I type AL, it filters down to Alabama. If I choose Alabama, the list vanishes, and the value is populated. If I click again, it shows the list filtered to Alabama. But what's weird is that if I click again, it closes the menu. And if I click again in a different location, it re-opens.
Adam: It seems odd that it's opening and closing in this situation
Matt_King: That feels like it's potentially anomalous behavior in our implementation, compared with other implementations that are out there
Adam: They shared some other component libraries that act this way and still others that don't
Matt_King: It kind of feels to me like the thing to click to intentionally open and close would be the chevron. If you're clicking anywhere else... Some could argue that from a hit-target perspective, why have just this one small target. But you're saying that one reason to click elsewhere is to move the caret
Adam: If I use my arrow keys to move the caret, that doesn't close the menu. So that's a bit of an inconsistency
Matt_King: It kind of feels like mouse users are getting UI side-effects. I imagine that for some users, that could be considered a negative side effect from an accessibility point of view
Adam: I think so. It's a noisy thing that happens that I suspect users wouldn't want. The list vanishes without their request
Matt_King: Thank you, I think that is very insightful. It must be what the questioner is asking us. It matches this scenario, and they explicitly used the word "toggle." That is the toggle behavior that seems like a potentially-undesirable side effect from the noise that it creates
Matt_King: Okay, we're out of time, but that discussion gave us a lot of clarity
Matt_King: To summarize, if the list is expanded and the user clicks inside the edit field in a manner that would appear to have an intent of moving the caret, the visibility of the list should not be affected by the intent to move the caret
Adam: Yes, I agree
Adam: Perhaps the reporter will be interested in filing a patch to correct our example
Matt_King: Yes, that would be nice! If they're working on a downstream example, perhaps they have the chops to make the necessary changes