Meeting minutes
Review agenda and next meeting date
<Matt_King> View agenda at https://
<Matt_King> Next meeting is Wednesday June 21
<Matt_King> Automation meeting on Monday June 19
Navigation menu button: conflicting test results
Feedback: "Open a menu in interaction mode" (Navigation Menu Button, Test 11) · Issue #960 · w3c/aria-at
<jugglinmike> s/subtopic:.*/subtopic: Inconsistent announcement of W3C Quick Links Menu "Open a menu in interaction mode" (Navigation Menu Button, Test 11) · Issue #959/
Alyssa: This concerns NVDA and Firefox. I was experience inconsistent behavior
IsaDC: I tested this twice and observed consistent results
IsaDC: I believe this was for the "Enter" key specifically
Alyssa: I know that the "Down arrow" key did it once, but it didn't the other times I tried
James_Scholes: I cannot get NVDA to say the role or the name no many how many times I try
Matt_King: For me, focus mode is never automatic. After hitting the "run setup" button, I have to change into focus mode
Matt_King: If I turn on focus mode when my focus is on the menu button, NVDA seems to expand the menu...
Matt_King: Ah, this is impacted by settings. It behaves differently now that I've reverted to NVDA's default settings
James_Scholes: if you review the speech history, you can see that it interrupts itself, so some of its output is never audible
Matt_King: Down arrow is definitely inconsistent, so I think it's safe to say that it doesn't do it
IsaDC: I'm experiencing that today, too. I will update my submission
James_Scholes: Even though we aren't testing key echo, if the AT speaks the key in response to the command, I think we should include that in the output.
Slider: conflicting test results
Matt_King: We have two issues here. One was raised by Hadi_Rangin
Feedback: "Increment a slider by one step in interaction mode" (Color Viewer Slider, Test 10)
IsaDC: JAWS was repeating itself
Matt_King: I can't reproduce this
Hadi_Rangin: I didn't see it, either. I'm pretty sure that I used default settings
Matt_King: Although I didn't make sure Firefox was up-to-date on my machine. Sometimes, with a focus event, it's possible that the browser could cause double-speak
[everyone checks the version of Firefox that is installed on their machines]
Matt_King: Hadi's was with Firefox 113
James_Scholes: So was IsaDC's
Matt_King: But the GitHub issue says Firefox version 112. This may be a bug in ARIA-AT App
James_Scholes: Both testers were using the same version of JAWS 2023.2303.144
Matt_King: That matches the version of JAWS I have installed right now
IsaDC: The repeated speech only occurs when I press "up" or "down", not when I press "right" or "left." And it only does it for the first press. It correctly speaks just one time for each subsequent press
Matt_King: I'm still not experiencing this, and the speech history looks correct, as well
IsaDC: If I refresh the page, it only says it once
James_Scholes: JAWS (more than NVDA) has problems with caching
James_Scholes: IsaDC copied this from the speech history, so I'm reluctant to call this a quirk and move on
Matt_King: I've hard-refreshed the browser, restarted JAWS, and ran the test again
Matt_King: I only heard the value read once, and it also only appears once in the speech history
IsaDC: I can no longer reproduce it. Now, JAWS says "129" followed by a pause as if it was going to continue speaking, but it says nothing more
IsaDC: I will update my test plan
Feedback: "Navigate forwards to a slider" (Color Viewer Slider, Test 5) · Issue #956 · w3c/aria-at
Matt_King: I don't see the redundant speech that Dylan recorded
Matt_King: I think we have to consider help messages when validating the output
James_Scholes: James Craig told us that something like 85% of VoiceOver users have hints turned off
Matt_King: I don't think we should "editorialize" tutor messages provided by default by screen readers
Matt_King: Like, saying that those are excessively verbose, doesn't seem right
James_Scholes: I think we need to be consistent with whether "help" text is subject to validation or not
Matt_King: Hints are part of the output, and we can have an opinion about what they say. However, if we say something about this particular hint, we'd have to say something about every single VoiceOver test
James_Scholes: Yes, that's why I thought that hints were not part of verdict assignment. But they have been subject to the criteria for "unexpected output"
James_Scholes: I suggest that we don't consider hints during verdict assignment (possibly to the degree that we don't collect it as AT responses)
Matt_King: I think we should be consistent: if the screen reader says something, it's part of the output, and we should record it
Matt_King: From a verdict assignment perspective, I think we can choose whether or not to validate the hint. For instance, if it repeats the hint, that would be excessive output
Matt_King: If the hint is just plain wrong, then I think we probably should say something about that being an undesirable behavior
James_Scholes: I'm concerned that we're giving testers inconsistent instruction--we're telling them to judge the hint text with some standards but not others
Hadi_Rangin: I think we should be able to label hints as excessive or incorrect, but choice of words should be the implementer's responsibility
Matt_King: I'm happy to fine-tune the wording of the checkboxes for undesirable behavior. In this case, I'd like to know more about Dylan's rationale
Hadi_Rangin: When we are recording the undesirable behavior, is it possible to make the "other" a separate checkbox?
Matt_King: The undesirable behaviors are all checkboxes
James_Scholes: Right, so you can check one or more