Meeting minutes
Review agenda and next meeting dates
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll move forward as proposed
Matt_King: No meeting Thursday May 30
Matt_King: Next community group meeting: Wednesday June 5
Matt_King: Next AT Driver Subgroup meeting: Monday June 10
jugglinmike: Confirming that the next BTT working group meeting is scheduled for Wednesday, June 12
Current status
Matt_King: 5 plans in candidate review: alert, command button, link, toggle button, radio group
Matt_King: Still prodding people for review and feedback
Matt_King: Goal: 6 recommended plans by June 30
Matt_King: 1 plan in draft review: Modal dialog
Matt_King: Next up: action menu button.
Matt_King: The APG task force made a pretty significant change to the menu button examples. Previously, they did not have "aria-expanded" set to "false" when the menu was closed
Matt_King: the task force revised its prior guidance and now has "aria-expanded" on it at all times
Matt_King: I'm wondering if IsaDC can get the code of the latest example updated to use the latest APG code
IsaDC: When was the change implemented?
Matt_King: In December or November. Definitely in the fourth quarter of 2023
IsaDC: This is going to be kind of really disruptive
Matt_King: It changes two things. We need to change the code that's used in the test case for menu button. I hope that's still a pretty light lift. It also changes the assertions which are applicable--it will add a third assertion to the existing two ("The state of 'collapsed' is conveyed")
James_Scholes: Would it be easier to update the code in-place rather than change the entire example
Matt_King: I'll leave it to you to make that decision
Matt_King: This applies to all three menu button examples. The one that is currently refactored is the "element.focus"
Matt_King: I think the intent was to do "active descendant". It would actually be preferable to do "active descendant" first
James_Scholes: has the script that pulls in the examples been updated to reflect the new directory structure in APG?
James_Scholes: I ask because this is something we haven't done in a long time
IsaDC: I was talking about make-v2
IsaDC: That script picked the wrong directory
Matt_King: It shouldn't be doing a fuzzy match on the directory name; it should be doing an exact match
IsaDC: I may have used the script incorrectly
James_Scholes: This script was authored by Bocoup
Matt_King: If it isn't working, please raise an issue so Bocoup can assist
howard-e: I just verified the problem. I will file the issue, and Bocoup can take it from there
James_Scholes: This entails a lot of work
Matt_King: We can move it down the calendar and move up the "color viewer slider"
James_Scholes: I can begin work on this issue, but I don't expect to complete it by next week
Matt_King: I'll update the plan
James_Scholes: When we do modify the menu button examples, should I modify all three or just the ones we're intending to refactor?
Matt_King: We should modify all three
James_Scholes: I'd like to make the reference changes in a pull request and someone else could refactor the tests
NVDA Bot response collection issue
Matt_King: It appears that the response-collection system is still returning data that appears to be coming from the old version of NVDA
howard-e: Corey at Bocoup has already replied to both issues listed on the agenda, and they are continuing to investigate
IsaDC: Some of the results were wrong, as well
Joe_Humbert: I noticed that some of the responses were inaccurate, as well
Joe_Humbert: I corrected those responses myself
Joe_Humbert: should I input the AT response for every command in the sequence, or for just the final command in the sequence?
Joe_Humbert: I noticed that the bot records AT responses for every command in the sequence
Matt_King: Yeah, it's expected that the bot is going to do that
Matt_King: IsaDC, I think we should take Joe_Humbert's approach for now, so that we're not blocked by issues with the bot. That means manually inputting the correct AT responses
Check in on dialog testing
Matt_King: We have two tests with conflicting VoiceOver results
Matt_King: First, on test number 6
Matt_King: This is issue 1071
Issue 1071
github: w3c/
IsaDC: We close the dialog, and VoiceOver exhibits the same issue we saw with Link
IsaDC: the cursor is not at the bottom of the "main" landmark
Joe_Humbert: I feel it's valid to say "main" because you are traveling back into the main landmark
Joe_Humbert: That's why I put "no unexpected behaviors"
Matt_King: It is a tiny bit overly verbose to me, but I understand why it's acceptable
Matt_King: every screen reader is a little different in when they announce whenever you jump over a landmark boundary
Joe_Humbert: we could treat this as present but not a problem, or we could interpret it as "overly verbose" (like we did with Link)
Matt_King: Based on Joe_Humbert's logic, it doesn't seem invalid
murray_moss: It sounds verbose to me, but not incorrect. I also recognize that the additional verbosity can be helpful for students
Matt_King: as long as excess verbosity is not problematic, then we don't classify it as a problem
Matt_King: I think in this case, we probably don't want to do that
IsaDC: I think it's unnecessary, but I can change my results to match Joe_Humbert's
Matt_King: The difference between "annoying" and plain "wrong" crosses an editorial line for us here
Matt_King: Let's go with IsaDC changing her results
Issue 1072
github: w3c/
IsaDC: The sequence number we get from the app when raising an issue is wrong
Matt_King: So we have a bug in our issue-raising button
howard-e: I can log that bug. I have a theory for what's going wrong, as well
Matt_King: So it's not test number 14. It's the test for going to the top of the dialog
IsaDC: It's actually test number 5
Matt_King: I'll edit the title of the issue
IsaDC: VoiceOver's cursor's doesn't move to the top of the dialog
IsaDC: If I remember correctly, it stays at the "add" button
Joe_Humbert: That matches my experience
IsaDC: I reported the "additional undesirable behavior" of "other"
Matt_King: I think that's the right thing to do here because it's essentially the lack of a desirable behavior
Joe_Humbert: I didn't know how to report it
Joe_Humbert: This would effect test number 6 as well because it's a similar result
Matt_King: Do we have the right command?
IsaDC: Yes, we do
Joe_Humbert: Yes. I checked because it seemed as though it wasn't doing anything
Matt_King: I think IsaDC's result is correct: this is a severe interoperability problem, and we should report it as a side-effect
Matt_King: I almost think we should modify the test to more precisely verify this
Matt_King: I don't want to put a failure in front of Apple if that failure is just a result of a dependency on a different bug
murray_moss: Are folks using an extended keyboard that has a "home" key?
Joe_Humbert: I plug in an external keyboard that has a physical "Home" key
murray_moss: I tried to do this with a non-extended keyboarding using "Fn" and "Left Arrow", and I got the command to work
murray_moss: I'm using 14.5
Joe_Humbert: I was on 14.4.1
VoiceOver bot status
jugglinmike: VoiceOver support is available on the staging server
jugglinmike: It's using macOS version 13
Matt_King: That's somewhat old; I wonder if we can update it
jugglinmike: We can look into that