Meeting minutes
Setup and Review Agenda
https://
Jem: Any requests for change to agenda?
Jem: Hearing none, we'll stick with the agenda as scheduled
Jem: Next meeting: August 26
Publication planning
Matt_King: Last week, we talked about setting September 3rd as our target. That's the Wednesday after Labor Day
Matt_King: We have two pull requests that are already merged and ready to go, and we have four more that are on the list for potential inclusion
Matt_King: I want to touch base on two of those which are just pending review
Matt_King: And we have Adam_Page's spin button change on the agenda
<Jem> w3c/
Matt_King: The first pending review is pull request #3320 (the pattern pages--adding a link to the "read this first" to the top")
Matt_King: We were awaiting a pull request to the "build" repository, and once that is confirmed good and ready-to-merge, then I would merge this one year
howard-e: That one hasn't been reviewed, yet, but it's been prioritized internally. I'm hoping it will be reviewed and merged later today
Matt_King: Got it
Matt_King: Then, the other pull request #3213
Matt_King: Jon believes the iOS problem has gone away
arigilmore: I tried it again. I updated my phone and cleared my cache, but I'm still seeing the same issue
Adam_Page: I haven't had a chance to check it out, yet, but I will
Matt_King: arigilmore, do you see the same problem on the production website?
arigilmore: On production, it came up normally. I tested again after updating and clearing my cache. I'm not sure what's going on
Matt_King: Maybe if either of you two reviewers have an opportunity to look at the actual code, feedback on potential causes of this bug would surely be helpful to Jon
PR 3354: Fix toolbar test failure
github: https://
Matt_King: This is howard-e's pull request
Matt_King: howard-e can you explain the change?
howard-e: Sure. This is for the toolbar. There's a set of options that it opens. Those options can then be clicked
howard-e: This is just a quick patch, but I think there's something more pressing, here.
howard-e: This patch works because closing the menu again before trying to open another option
howard-e: I'm not sure why it works this way. I stepped back through the Git history, and the behavior is present there, too
howard-e: I can't replicate this normally; it's behavior we observe in the test
Matt_King: If you go to the APG and go to the toolbar and click a menu item, does it actually close?
howard-e: Yes
Matt_King: Is it closing when you operate it with a keyboard in production?
howard-e: Yes, it is. I'm not sure what's happening
Matt_King: So in the headless browser environment, the menu appears to stay open
howard-e: Correct
howard-e: The change here just checks to see if the menu is open
Matt_King: So this right here is just a change to the regression test code, right
howard-e: Yes
howard-e: I want to leave the issue open, though, to investigate further why it is like this
Matt_King: Can we get a reviewer on this pull request?
Adam_Page: I'll do that!
Matt_King: Thank you, Adam_Page
Jem: In the issue, it says aria-checked, but the pattern talks about a button with aria-expanded
howard-e: There is a button that's controlling the menu. It has an "aria-expanded" attribute on it.
Matt_King: That's correct; it should have "aria-expanded"
howard-e: The test loops through the options when the option is opened, and it clicks on one. It expects that aria-expanded should be set to "false", and that doesn't happen
Jem: But the issue says "aria-checked" and not "aria-expanded"
howard-e: The assertion itself isn't compromised; it's the way to get to the assertion
Jem: So can we ignore the assertion about aria-checked?
howard-e: Yes, that's fine
Matt_King: howard-e is saying that the fundamental issue is that we should need this workaround. Something it preventing "aria-checked" from being set in the test environment (and outside the environment, it works appropriately)
howard-e: That's correct
Matt_King: Okay, yes. This workaround bugs me, so I support digging deeper
Matt_King: I guess we might want to remove this change later if we can figure out why we need it in the first place
howard-e: I agree
Matt_King: Okay, then I guess we want a comment in the code reminding ourselves to remove it in the future
howard-e: I can do that
howard-e: This week, I'm going to try to prioritize doing the research here
Matt_King: Great. This points to a potential problem in the test environment itself
PR 3328: Add Quantity Spin Button
github: w3c/
Matt_King: We want to get reviewers assigned
Adam_Page: I've addressed the failing tests
Matt_King: I'm assigned as a reviewer, but we don't have anybody else looking at the code or the visual design
Adam_Page: howard-e just gave me a review, but it would be great to have more reviewers
arigilmore: I can do a review of the visual design
Adam_Page: Thanks, arigilmore
Jem: I've assigned arigilmore
siri: You can add me, too
Matt_King: Great. Siri, if you want to test it on mobile
siri: I will try to do it over the weekend
Adam_Page: I'm going on vacation starting Wednesday of next week, so if we want to have this ready for the next publication, then I will need review feedback by Tuesday
Jem: I'll add a link directly to the example
PR 3311: Add note about pointer activation and roving tabindex
github: w3c/
Matt_King: This is a change to the keyboard section. Patrick submitted a pull request that's related to an issue he raised
<siri> can you add me as reveiwer to the 3328 bug?
Matt_King: This kind of gets at the changes that were made to the editor menu bar
Matt_King: I've added myself as a reviewer
Matt_King: I will be looking at it from the point of clarity. From an editorial standpoint: "is it saying what it says clearly?"
Matt_King: I'd like someone else to review and decide if it is saying what it needs to say
arigilmore: I can try to take a look
Matt_King: Okay, that would be helpful
Jem: I've assigned arigilmore
Issue 3353: Select-Only Combobox example: list popup not operable with arrows when Voice Over is on
github: w3c/
Jem: It was opened last week
Matt_King: Someone is getting different behavior in Chrome versus Safari
Matt_King: We need to figure out if this is related to browser or screen reader functionality? Or is it something to do with the select-only combobox code?
Matt_King: Is there anyone who's available to do some root-cause analysis
Adam_Page: I'm unable to reproduce this. I think it would be good to ask the reporter for the software versions in use
Matt_King: Could you add a comment, Adam_Page, with your versions? Both macOS and Chrome?
<Jem> w3c/
Adam_Page: You bet. I'll also try it on a second macBook (since I have one handy)
Matt_King: Awesome!
Matt_King: I'm not going to label this, yet, because we don't know if it's a bug or not
PR 3304 : Removed timeout code for reseting search string in select only combobox
github: w3c/
Matt_King: This is Jon's pull request, and it's a draft
Matt_King: I asked Jon some questions in a comment
Matt_King: I have a feeling that this is not a pull request to make a change
Matt_King: I suggest we skip this until we can discuss with Jon