Meeting minutes
<lola_> Hey Matt, in case you haven't seen my email this is the correct zoom link: https://
Review agenda and next meeting dates
Matt_King: Next meeting: February 22
Automation subgroup meeting planning
Matt_King: Perhaps we can have two meetings each month, scheduling them to surround the monthly W3C Browser Testing and Tools meeting
Matt_King: That is: one monthly meeting the week before Browser Testing and Tools ("BTT") and another meeting the week after BTT
Michael_Fairchild: or maybe we only schedule one new meeting to occur before BTT, and then use part of this meeting to follow-up on anything learned from the BTT meeting
Matt_King: I like that
Matt_King: Should we create a poll to asynchronously find a time for the meeting?
lola: I like that idea. I can set up the poll
Matt_King: Okay. Let's keep the Monday @ noon PST option as a starting point (since it's what we used in 2023)
Matt_King: We can rule out times that conflict with W3C meetings...
Matt_King: Maybe we should just use 9, 10, 11, and 12 on Monday through Thursday
Matt_King: During the first week of every month
lola: Sure. I can send out that poll
<Matt_King> https://
Matt_King: Let's get a poll set up like that by tomorrow, with the expectation that we can open it up for responses tomorrow, share the poll at the next Community Group meeting, and share the results in two weeks' time
<Joe_Humbert> Yes
Deep dive into new radio test plan
Matt_King: I'm working on this plan
Matt_King: We refactored it from the old format to the new format; that was pretty automated
Matt_King: But because we went from having both "Reading mode" tests and "interaction mode" tests, the refactoring created some duplicates
Matt_King: I've been removing the duplicates and reconsidering their sequence and names
Matt_King: I'm also starting to wonder whether we have too many tests
Matt_King: I have a preview for my current work on these tests; there's a link in the agenda
https://
Matt_King: The first question I have is about the sequencing of the tests
Matt_King: When I was first de-duplicating, I had organized them according to the direction of interaction (first all the tests for navigating forward, then for all the tests navigating backward, etc.)
Matt_King: But I started wondering if a more nuanced structure would be preferable, e.g. all the tests for navigating forward *within the group* followed by all the tests for moving backwards *into the group*, then for navigating forward *out of the group* and so on
Joe_Humbert: I don't care too much about the sequencing because there is so much setup for each test, that each one feels pretty distinct
Matt_King: Okay, then I guess the sequence really only matters for folks who are reading reports
Matt_King: The question becomes, "does the ordering feel like it's easy to consume?"
Matt_King: Maybe we should include that as a research question when we conduct usability testing on the report site
Joe_Humbert: I don't think it matters much, provided that the tests themselves are easy to understand
Matt_King: In the radio group (for either of the first two tests), if you tab forward into the group and none of the buttons are checked, it goes to the first button
Matt_King: It also goes to the first button if you tab backwards
Matt_King: However, if you navigate backwards into the group, then the button you go to is the third button
Matt_King: I waffled back and forth about how to express this as an expectation in the system
Matt_King: I also wondered if maybe we should simply not test what happens when you tab backwards into a radio group when none of the buttons are checked
Matt_King: There are three tests where you tab forward and two tests where you tab backwards
Matt_King: That feels sufficient to me, but there's an asymmetry there, and I'm wondering if there's value to adding another test beyond preserving symmetry
Joe_Humbert: I don't think there's any value without a reasonable expectation that doing so might yield different results
Matt_King: Well, we never know. But it does seem like it would be a very bizarre bug to get wrong output for that specific case (that is, for tabbing backward to an unchecked radio button)
Matt_King: I think the probability that it ever yields different output is incredibly low. That's why I'm thinking about not doing anything to resolve this
Matt_King: Maybe another thing to think about is: if that one thing did fail, what would the consequences be for users? It doesn't seem to me like it would be a critical failure...
Matt_King: Beyond that, I'm wondering if there are any missing tests or missing assertions
Joe_Humbert: I won't have time to review for that before next week
Matt_King: Well, we can do further review after this is merged. I'll keep this on the agenda for next time