Meeting minutes
Agenda Review and Next Meeting Date
<Matt_King> Next meeting on April 13.
<Matt_King> See agenda for today, April 6, at https://
AT Support Table Launch Update
Matt_King: Overall, with a launch scheduled for next Thursday, I think we're a little behind. I'm still hoping to pull it off, though
Matt_King: AT support tables are in the main branch and in the preview of the main branch for aria-practices
Matt_King: All the feedback so far is good
Matt_King: They are 99% ready to go. The third topic on the agenda is about the remaining 1%
Matt_King: As for the blog post, Daniel at W3C was supposed to get me set up. I need to follow up with him. I have a 90% draft, but I haven't shared it, yet
Matt_King: I'm going to put it in Google Docs to share it
Matt_King: I'd like to be able to link to something about PAC's contributions and Bocoup's contributions, on their respective websites
Matt_King: I'll be happy to share the draft with any members of the community group who are interested. I'd like to do it on an individual basis
Matt_King: It has to cover a lot of ground since we haven't publicized our work much during the last 18 months or so
Matt_King: I still have to meet with Apple and Vispero. Preparing a draft of the blog post was a prerequisite for those meetings
Current testing check-in
Matt_King: The goal of our current testing is to add more browser/screen reader combinations to the support tables
Matt_King: We can continue to add more, and they'll automatically show up in the APG as we publish them
James_Scholes: JAWS with Firefox. Command Button all complete with no conflicts same for Toggle Button
James_Scholes: NVDA with Firefox: Command Button all complete with no conflicts same for Toggle Button
James_Scholes: VoiceOver and Chrome: Command button--all complete with 2 conflicts. Toggle Button--all complete with 7 conflicts
James_Scholes: I think we need to go through those conflicts and raise issues for the ones we can't resolve
Matt_King: I will try a few of these to make sure that they move through the process okay and make it into the production support tables
Matt_King: Alert Link and Radio, for JAWS and Firefox, NVDA and Firefox, and VoiceOver and Chrome, all need a second tester
Dylan_Sheffer: I can take Alert, Link, and Radio for Jaws&Firefox
Alyssa: I can take Alert, Link, and Radio for NVDA&Firefox
JoeHumbert: I can take Alert, Link, and Radio for VoiceOver&Chrome
James_Scholes: Great! Testers: please work on those in alphabetical order (that is: first Alert, then Link, and finally Radio)
michael_fairchild: This is off-topic, but after reviewing the support tables, I'm wondering... For JAWS and Safari, I see "no data". Is that accurate, or should I see something along the lines of "not applicable"
Matt_King: It will one day, but for now, we're saying "no data". It's a generic thing that works also for cases that are valid combinations but for which we have not collected data, yet
Matt_King: In the future, the system will differentiate between table cells where data is "not available" data data cells that are "not applicable" (i.e. when the browser/AT combination isn't possible)
Radio plan update for support table launch
Matt_King: JAWS is showing 99% support but it should show 100%
Matt_King: We have reviewed the specific test and command with Vispero and have agreed to remove it
Matt_King: We did remove two instances, but two still remain
We're discussing how to fix this in w3c/
Matt_King: The test itself is valid, it's just that Vispero objected to some commands
Matt_King: If you are in reading mode, you have the reading cursor inside a radio group, and you're navigating out of the radio group
Matt_King: We have two tests: one for navigating out of the START of the radio group (navigating backwards, up the page), and one for navigating out of the END of the radio group (navigating forward)
Matt_King: The discussion to date has been in the issue about the first test
Matt_King: There are two assertions related to the nearby link, and one related to the boundary of the radio group
Matt_King: When you use Tab or Shift+Tab, JAWS doesn't tell you anything about the boundary of the radio group
Matt_King: When we spoke with Vispero, we agreed that the test should not assert anything about the boundary of the radio group
James_Scholes: We removed the assertions from the "interaction mode" tests
James_Scholes: But if we remove the assertion from this test, it will apply to both the Tab key and the arrow keys, which we don't want to do
Matt_King: My suggestion was that we just don't test Tab or Shift+Tab
Matt_King: My reasoning is that if you're exiting an element with the Tab key, there are no expectations that the screen reader do anything related to the element that you're leaving.
Matt_King: I described this in my first comment on the issue
michael_fairchild: Am I understanding correctly that there's a potential scenario where it might not be clear that you're leaving a radio group when you're tabbing or shift+tabbing
James_Scholes: the feedback that I've received is that people don't need to know that. If you're tabbing out of a radio group, then it's implied that you've left the radio group because you are no longer looking at a radio group member
James_Scholes: it can be significantly confusing if you hear an announcement that you're leaving a radio group, followed by an announcement that you're entering a radio group. Particularly if they both have names
Alyssa: that's my take, as well
michael_fairchild: I think the path forward is to remove the command to "Tab" or "Shift+Tab", and I'm trying to understand why we wouldn't do that
James_Scholes: I'm hesitant to simply remove the command for two reasons. First has to do with my personal experience with NVDA's quirks. I would like our tests to exercise what appears to be a relevant corner-case for that AT. Second reason: making a change like that would make this test an outlier, and therefore the test plan an outlier. Everywhere else, we follow a similar practice about moving focus out of a "thing" and asserting i[CUT]
Matt_King: I agree with the second part. We could certainly file an issue to normalize around this.
James_Scholes: When you carry out a task, and the screen reader automatically switches to another mode. For instance, when tabbing out of a radio group, we may want to assert that reading mode is retained. In other case, we may want to assert that tabbing out of certain elements causes a change in mode. That's future work, but it means tabbing out of radio group will be an important thing to test.
Alyssa: could the assertion be that you hit the next element? So, for instance, "after you press Tab, it should announce this link"?
James_Scholes: Those assertions are already present. We want to be sure that the boundary is announced in reading mode, but not when moving focus
Matt_King: In this test, to navigate out, we have arrow keys and tab. And they can't say different things. The proposal here is just to remove Tab.
Matt_King: Even in the case of mode switching, that only happens with Tab and Enter. And Enter is a different kind of test from Tab. So moving with Tab is going to have to be a separate test
Matt_King: In the radio group plan, no matter what you go to outside of it--the plan isn't about testing links. It's about testing what goes on inside the radio group. If we were to ever find a bug relating to, for instance, tabbing to a listbox outside of a radiogroup. That is still a listbox problem, and it's not related to radio group. And those are such extreme edge cases that I think we have to be careful about expanding the scope[CUT]
Matt_King: For the immediate situation: removing Tab and Shift+Tab from these two tests would bring JAWS up to 100% based on our agreement with Vispero. If we were to add additional tests later (related to mode switching), THEN, in those specific cases, that could end up bringing back these assertions relating to Tab. But I think that's a different change and a different discussion. Would you agree with that?
James_Scholes: I agree. My overarching concern is that we have (what I consider) a blocking issue relating to updating test plans in such a significant way that they can no longer be brought into the App without invalidating test results that are still perfectly valid.
James_Scholes: In the short term, speaking strictly from the point of view from unblocking the support tables workstream, I agree that it's an acceptable way forward that doesn't undermine things too much
James_Scholes: But I don't want to miss the opportunity to acknowledge that we have a significant issue that needs a resolution
James_Scholes: We would like to be able to make changes without needing the entire plan to be re-tested
James_Scholes: No screen reader vendor has raised an issue with the other assertions in this test. Arguably, if we're talking about removing this assertion from this command, we should be talking about removing it from the test for "interaction mode"
James_Scholes: I don't think we have a good answer for documenting why we omit certain assertions. It will be hard for others without the context of this meeting to understand this
James_Scholes: Do we want to add an assertion which states, "group boundary is NOT conveyed"
Matt_King: I'm concerned about the scope of our testing becoming too granular
James_Scholes: I agree. Evolving the test approaches is important, and I don't want to push back on that. I want to make sure we're aligned on the departures
James_Scholes: To complete the circle, we should also remove Tab and Shift+Tab when existing radio group. That will bring it in line with JAWS+NVDA.
Matt_King: I think that's where we want to go for all test plans.
James_Scholes: Let's make the change and document our considerations in the pull request
Matt_King: I'm fine with that
michael_fairchild: I'm fine with that, too