Meeting minutes
<mfairchild> regrets for today
Review agenda and next meeting dates
https://
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: We may want to cancel next week's meeting
Matt_King: The way the outlook appears right now, we won't have new stuff for the test queue this week. That will all be available the following week
Matt_King: So we might be able to save people some time by not having a meeting next week
Matt_King: Does anybody anticipate anything that I'm not anticipating that suggests we should meet next week?
IsaDC: Not from our side, I don't think
Matt_King: Okay. I'll make a decision based on how things are looking after Monday's meeting with PAC
Matt_King: And also based on anything else that may turn up
Matt_King: Following Community Group Meeting would be: Wednesday May 21
Matt_King: Next AT Driver Subgroup meeting: Monday May 12
Current status
Matt_King: We have three things in draft review, but they're all held up by one thing or another
Matt_King: We'll talk about radio group when we talk about arrow keys and NVDA later on in this meeting
Matt_King: Vertical temperature slider has incoming changes which may be done by the end of the month
Matt_King: As for the disclosure navigation: we could re-evaluate and push it on through, but it's kind of a waste of time when we know at least (at a minimum) are coming to JAWS
Matt_King: We've learned that those changes in JAWS won't be available in the May release, but instead in the July release
Matt_King: As for what's coming next
Matt_King: James and IsaDC and I keep running into a variety of problems which make some options untenable at the current moment
Matt_King: IsaDC is planning to get the work on according done by the end of next week
Matt_King: The next three that I have listed here were all scheduled to get done in April or May, but they all ran into strange problems
Matt_King: There isn't clarity in the HTML AAM about how screen readers should handle lists made with dl/dt elements.
Matt_King: But it's not really necessary to use that specific structure in the APG, so James is going to raise an issue in the next few days about that
Matt_King: The image description one is even messier because we actually don't know what screen reader expectations ought to be for figures (especially for labeling figures)
Matt_King: I have an action item to file an issue against HTML AAM or maybe even accname
Matt_King: But the uncertainty there may delay this work for a really long time
Matt_King: In summary, those are the kinds of technicalities which are delaying the upcoming work
Matt_King: But it will be accordion next, and the spreadsheet shows what will follow that (I believe it's going to be the spin button)
Re-run of JAWS for color viewer slider
Matt_King: I re-tested this with not the exact same build that Hadi was using, but with a beta build that followed Hadi's. Brett assured me that there were no relevant changes between these releases. My results matched Joe's results and not Hadi's results
Matt_King: I have a feeling this was just a copy-and-paste error on Hadi's part
Matt_King: Can you e-mail Hadi, IsaDC?
IsaDC: Sure
IsaDC: Were they running the same version?
Matt_King: No, Joe was running the March version and Hadi was running the April version. I believe that's what we determined from the meeting minutes, anyway
Matt_King: I think this is going to be a fast fix. Once that's done, we can just push this
Arrow keys in NVDA test plans
Matt_King: There is a setting in NVDA that is enabled by default. When things are visually on the same line, the arrow key will put a whole bunch of elements (in this case, 5 radio buttons) on the same line, so that the arrow key doesn't semantically separate them; it just reads them all at once
Matt_King: That's different from how both JAWS and VoiceOver work by default
Matt_King: This has consequences for the rating radio group
Matt_King: I went back and looked at what we did for the other two radio groups, and it's quite interesting that we did use "insert + up arrow" for requesting information, but we left the arrow keys out for the "browse mode" testing for navigating from one radio group button to another
Matt_King: I'm not sure why that is
Matt_King: Then I started thinking about this and kind of wondering: would the community group be aligned with expecting NVDA to by default NOT combining these things? This is about conveying semantics and not about conveying visual information
Matt_King: It doesn't feel like an inconsistency that we want to support
James: I think the screen layout setting in NVDA is not a faithful representation of what's on the screen. There are cases where some things are on the same line, but NVDA will not convey them as such. I think there are inconsistencies and limitations from what they can get from the browser
James: The setting is intended to convey things on the same line
Matt_King: I'm saying that for that to be the default behavior--so it gives a different semantic behavior by default
Matt_King: In some cases, the arrow key can move you to a specific radio button in a radio group, but in other cases, it cannot
Matt_King: Both cases are semantically equivalent; the difference between those cases depends only on the CSS
Matt_King: It either means we have to tell people (e.g. testers), "never use the arrow key". But real-life user do!
Matt_King: ...Or, we could possibly say to NVAccess: "fix the interoperability bugs that we're finding by changing the default value of this setting""
James: The aim of the setting is not to change the semantics but to change how the controls are conveyed
IsaDC: It's for the navigation--how you move through the buttons. You can't do it with the arrow keys
James: I think the default is terrible, and so did all the folks who responded to my informal Twitter poll
James: That's just my opinion, though
James: I can't pick out all the information--that's why I dislike the setting
James: I agree from a cognitive perspective. But that isn't semantic; it's just a subjective opinions
IsaDC: This concerns the tests for navigate to next and previous radio button, right?
Matt_King: Yes
Matt_King: In one case, you get one button, and in another case, you get a bunch of buttons, and so the way the command is behaving, by default, is giving you a completely different amount of--I guess you can distinguish, if you listen closely, you may be able to differentiate the radio button labels
James: We have discussed a number of cases where there is a fine line between objectivity and opinion. And we agree that we're not trying to change the screen readers' decisions about how they present information, as long as they convey that information.
IsaDC: What is the output we seek from this issue?
Matt_King: Essentially, we don't know when it's okay to test with the arrow keys and when it's not
Matt_King: What we're currently telling the world is that the commands you can use for this pattern vary based on visual presentation. So the commands end up based not on the pattern but on the visual presentation of the pattern
James: In that informal poll I conducted, respondents offered a bunch of work arounds
James: The APG could make a vertical radio button example
James: It feels like we're overstepping the mark, even though we all agree that the default behavior is not good
Matt_King: That's exactly my question: would we be overstepping the mark on this case?
Matt_King: And I'm hearing that you think it's better to not test with the arrow keys for NVDA
IsaDC: Do we have other exceptions like this?
IsaDC: For other screen readers, that is
Matt_King: None come to mind
James: For JAWS, we almost always add an extra arrow key press because it adds inline "fake" text
Matt_King: We do that for VoiceOver, as well. NVDA is the outlier in that case
IsaDC: I think testing the arrow keys would bring more issues
James: If we test this and fail NVDA, I think we're going to get push back from NVAccess or elsewhere that essentially, "it didn't fail but it just didn't act the way you wanted"
Louis: I agree with James
James: It became apparent from NVAccess (because Jamie Teh replied) that they don't have access to data for how users change settings
James: I do think that a company like Vispero will think about this a lot more--they have the resources to do so, and they have more avenues for structured feedback, etc
James: I think that's a shame because whenever I've tried to get people using NVDA who are more comfortable with JAWS, there are defaults which trip them up
James: I think, realistically, NVAccess will just tell us, "it's only one keystroke for users to turn this off"
Matt_King: I'm hearing that it is an overreach for us to weigh in on this particular behavior
Matt_King: I agree that ARIA-AT isn't always the way to push for change
Matt_King: But we should still be consistent within ARIA-AT
Matt_King: We tested with "insert + up arrow" on another test plan, but that's only due to luck
Matt_King: I'm wondering: for consistency within the tests, even if "insert + up arrow" happens to work in some tests, should we include that command?
Matt_King: Or should we use the same commands across all radio group test plans?
James: All three radio group test plans in the APG put the radio groups on the same line
Matt_King: I just ran through them last night, and the pizza crust ones, for example, were putting them on separate lines
James: The best way to test NVDA with defaults is to make a portable version
Matt_King: Henceforth, I will always use a portable NVDA. Is that really the fastest way?
James: You can also rename your NVDA folder in your AppData folder and restart it
Matt_King: How did people get the "insert + up arrow" results that they got for radio button activedescendent?
Matt_King: The output that people recorded was not the options. Does that mean they weren't using the defaults?
IsaDC: I was using the dafaults
Matt_King: Oh, but that was bot output!
IsaDC: I always double-check the bot output
Matt_King: I'm questioning all the NVDA research I did last night
James: I wonder if they act differently in the APG than they do in ARIA-AT
IsaDC: They shouldn't
James: they all work the same for me with the absolute defaults (I haven't even changed the synthesizer). Even in the APG
Matt_King: Then our reports are wrong
James: the only thing I can see changing that is if the browser window was too small
Matt_King: Sometimes the setup script doesn't work correctly if the window is too small
IsaDC: My concern in that case is for the other two
James: I can't make those appear on separately lines by zooming in, either
Matt_King: I think we're going to remove "up", "down", and "insert+up" from all these test plans
Matt_King: But now, I'm very concerned about how we got the results that we got
Matt_King: My only theory is that the bot reported incorrect responses and that no one corrected it
James: It is possible that the bot was in the wrong mode
Matt_King: Yes, because focus mode would change the "insert + up" behavior
Matt_King: But I was getting blank responses when I was in focus mode
Matt_King: Okay, this turned out to be much more complicated than I expected!
James: I'll share a link to the issue I filed against NVDA
<ChrisCuellar> James: nvaccess/
Matt_King: Do we re-run the test plans first? Or do we change them, first?
Matt_King: Let's go with the active descendant. Add the current version of the test plan to the queue, run it with a bot, and let's have a human go through it to determine if it is giving correct output. Let's make sure that whatever human reviews it is truly using defaults (allowing only changes to speech rate change)
Matt_King: Make sure we're using the latest NVDA with defaults
jugglinmike: The NVDA bot is using version 2024.4.1
jugglinmike: https://
IsaDC: I am using 2024.4.2
Matt_King: I don't know if or how much that will matter
Matt_King: We'll run it with the bot and just see what it does
Matt_King: this could also be due to a mode problem as James suggested earlier
Matt_King: We can dig in if we see a discrepancy
Arrow keys in NVDA test plans
Matt_King: We're just about out of time
ChrisCuellar: It's okay, this isn't urgent
ChrisCuellar: We are running the tests in automation over and over again to detect ways that the automation system is inconsistent
ChrisCuellar: In that process, we identified an inconsistency that we could reproduce manually
ChrisCuellar: And it's not clear how we should handle that
Matt_King: Oh, that's interesting
Matt_King: Let's plan to talk about it next time
ChrisCuellar: Sounds good!