Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Requests for changes to agenda?
IsaDC: I'd like to add issue #1062 to our discussion of the dialog testing
Matt_King: Next AT Driver Subgroup meeting: Monday May 13
Matt_King: No meeting Thursday May 16 (I will be at Access U)
Matt_King: Next community group meeting: Wednesday May 22 (I will not be able to attend, though)
Current status
Matt_King: We have 5 tests plans in "recommended" phase, our goal is 6
Matt_King: 5 plans in candidate review: alert, command button, link, toggle button, radio group
Matt_King: 1 plan in draft review: Modal dialog
Matt_King: Goal date is June 30
Matt_King: Next up: action menu button.
Check in on dialog testing
Feedback: "Open a modal dialog" (Modal Dialog Example, Test 1, V24.05.02)
github: w3c/
IsaDC: the output that was reported didn't match the version of NVDA that I was using
Matt_King: Did you change the output?
IsaDC: No, I wanted to bring it up here to learn what would be the most appropriate response
Matt_King: Maybe changing it isn't a good idea because the version is going to be the version that the NVDA Bot uses
Matt_King: So then we would have to analyze the output based on that older version
Matt_King: Is the newer output going to cause the test outcomes to be different from the older output?
IsaDC: Yes because NVDA fixed many issues that we observed before
IsaDC: For instance, it used to say "dialog" twice, but now, it does not
IsaDC: So the change in behavior is significant
Matt_King: jugglinmike: Can we have an update on the NVDA version? And if so, when?
jugglinmike: Yes, if all goes well, we should be able to do this update in less than a day.
jugglinmike: With any change to NVDA, there is a risk that the new version interferes with the functionality of the NVDA AT Driver Server which we are maintaining
jugglinmike: Since this is the first time we've updated NVDA for automation, we don't yet have a good idea of how likely it is for the new version to cause problems
jugglinmike: Over time, we will develop an intuition on that.
jugglinmike: For the moment, it will be wise to allow for delays that would come from troubleshooting problems like that
Matt_King: Okay. So, what should we do in the mean time?
IsaDC: The changes are quite significant
Matt_King: Okay, then maybe we should put the NVDA testing on hold for one week and then make a decision based on where we stand with the new version's availability
Matt_King: Let's use this issue as a base for asynchronous decision-making. James_Scholes can report on the new version of NVDA's compatibility with the NVDA AT Driver server, and jugglinmike can post an estimate on the timeline for updating ARIA-AT App with the new NVDA version
IsaDC: Sounds good
Hadi's question
Hadi: We open a dialog box and we're checking if role information is conveyed
Hadi: one test for Chrome and JAWS is to open the dialog box in PC mode
Hadi: the question is "does JAWS switch from virtual mode to PC mode?"
Hadi: This makes sense when JAWS starts in Virtual Mode, but not when it starts in PC mode
IsaDC: is that for test 1?
Hadi: Yes
Matt_King: In test 1, under JAWS, the first one is "space with virtual cursor active". That one has the mode switch, and it should
Matt_King: The next command is "space with PC cursor". That one, the "switch mode" assertion is there
Matt_King: I think it has to be removed
Hadi: I think it makes sense for it to be the other way around. I have seen the AT switch from PC mode to virtual mode
Matt_King: In this case, it should not. If the focus was going to content (e.g. a link), it would stay in virtual cursor mode, but if the focus was going to an input (as it is in this case--an edit field), the PC cursor should be active
Matt_King: It looks like it's there for NVDA as well...
Matt_King: So we need an exception
IsaDC: When we raise an issue from the app, we get different test numbering
Matt_King: The app needs more fine-grained issue reporting functionality. I'm going to file an issue with more detail on this
Hadi: In the second test, when the dialog starts open with a focus on the "cancel" button. When I am pressing "enter" on the "cancel" button, JAWS is entering a kind of weird mode which is not acting properly
Hadi: I reloaded JAWS, but the behavior persisted
Hadi: Do you folks ever run into situations where JAWS is misbehaving and not reading correctly as a result?
IsaDC: Sometimes. I usually close the window which holds the test, then re-open, press the "run setup script" button, and try again
Hadi: I tried those things. Should I mention that in my report, or should I restart my computer?
Matt_King: I'm trying that right now, and JAWS isn't doing anything unusual for me
Hadi: Probably the problem is that JAWS is not in a good state
Matt_King: It seems to be very consistent for me right now
IsaDC: We'll be testing that today, as well. If we run into any problems, I'll report that in a new issue
Matt_King: Is May 17 completion possible?
Matt_King: We have a little bit of a wrench thrown into the plan with the NVDA automation update
Matt_King: Maybe we can at least get JAWS and VoiceOver done in time for May 17
IsaDC: I think that should be possible by the next meeting, two weeks from today
Hadi: Same for me
Menu button feedback
Matt_King: James Craig raised a bunch of issues, which is great
Matt_King: I commented on all of them, but there's one in particular that I think we need to discuss here
Feedback: "Navigate to the first item in a menu" (Action Menu Button Example Using aria-activedescendant, Test 18, V22.03.17) · Issue #1060 · w3c/aria-at
github: w3c/
Matt_King: James had three points where he argued that certain assertions were invalid and should be removed
Matt_King: first, "position of focused item" -- expectation filed separately as #1058
Matt_King: second, "number of items in menu is never conveyed while switching between items in a menu."
Matt_King: third, "menu item role is never repeated while switching between items in a menu, native or web. It would be redundant."
James_Scholes: I find the suggestion that we should convey the position and the total as being out-of-sync with other screen readers and also with general screen reader users' expectations
Matt_King: I thought we were all aligned on the idea that, given the semantics of MUST and SHOULD, that generally information about set sizes ought to be asserted with SHOULD
IsaDC: Yeah, if we were talking about "MAY", that would be a problem
James_Scholes: Okay, that makes sense
Matt_King: It doesn't seem like a screen reader should be repeating the role inside each one of these containers
James_Scholes: It's difficult because there are cases where screen readers DO do that, and you might find it off-putting if they didn't. Like in a tab list, for example
James_Scholes: Or what JAWS and NVDA would call a tab control
Matt_King: We're also starting to see things like "close" buttons in tab lists, so there might be other things in there
Matt_King: That's currently not valid, to be clear, but it might become valid with ARIA Actions
James_Scholes: I think it would be actively annoying if the AT announced that everything in a menu is a menu item, though
Matt_King: So do we want this to be a "MAY"?
James_Scholes: Well, I really think it SHOULDN'T do that kind of menu item announcement
James_Scholes: I think that if we didn't include it at all, then someone may be more likely to highlight it as extra verbosity if they encountered it
James_Scholes: but most testers would probably not consider if excessively verbose if we explicitly allowed it with a MAY assertion
Matt_King: This is just when navigating from one to another, but if you are READING the item, then it ought to tell you (since you might not remember or you might be distracted)
Matt_King: Any objections?
Matt_King: Hearing none, we'll stick with that.
Enhancements to APG support tables
Lola_Odelola: are we still targeting Global Accessibility Awareness Day for public announcements?
Matt_King: Given that multiple people are attending Access U next week, I think we are going to drop that deadline
Matt_King: Everyone's feedback on the tables has been incorporated, and I think they are much better as a result of their participation
Upcoming Test Queue Changes
Matt_King: In the next couple weeks, an important change is coming to help us do testing while test plans are in the "recommended" phase
Matt_King: right now, we don't require testers to use a specific version of an AT
Matt_King: When a test plan is recommended, and a new version of an AT comes out, we need to re-run the test plan with that new version specifically
Matt_King: That's not currently possible, but the next version of the test queue will support it
Matt_King: We're looking at the functionality being available in the "sandbox" server on next Wednesday
Matt_King: That's Wednesday, May 15
howard-e: I think we're planning on the Wednesday after that, which is May 22
Matt_King: Understood. IsaDC and James_Scholes, you can put that date on your calendar for testing
AT Driver Update
Lola_Odelola: I expected to have a automation sub-group meeting immediately before the BTT in order to prepare. That didn't happen this week, so I wanted to check if there is a scheduling problem
Matt_King: I think this is just a problem with this particular month and its impact on the two meetings' schedules
<Sam_Shaw> jugglinmike: People are hearing the term Glass pane for the first time so I'll define it. When you run the AT Driver in safari, you get a notice that says you can't interact with the content:
<Sam_Shaw> jugglinmike: This present problems for us because we are using automation to run a test that is in the glass pane state.
<Sam_Shaw> jugglinmike: We brought this issue to the BTT group
<Sam_Shaw> jugglinmike: However we are going to automate AT Driver with webdriver, and Apple is not going to like it
<Sam_Shaw> jugglinmike: We asked other browser developers if they plan to implement a glass pane
<Sam_Shaw> jugglinmike: We have not heard back from Chrome, Firefox said no they don't plan to do this
<Sam_Shaw> Matt_King: I'm really interested in Apples response, James craig they weren't going to support BTT as you can do with with Apple scripts
<Sam_Shaw> Lola: I would hesitate to put to much into a response from Apple, because the glass pane presents other issues that they are facing