18:56:01 RRSAgent has joined #aria-at 18:56:06 logging to https://www.w3.org/2023/04/06-aria-at-irc 18:56:06 RRSAgent, make logs Public 18:56:07 please title this meeting ("meeting: ..."), Matt_King 18:56:25 MEETING: ARIA and Assistive Technologies Community Group 18:56:34 CHAIR: Matt King 18:56:38 present+ 18:56:44 rrsagent, make minutes 18:56:45 I have made the request to generate https://www.w3.org/2023/04/06-aria-at-minutes.html Matt_King 18:57:48 JoeHumbert has joined #aria-at 18:57:53 TOPIC: Agenda Review and Next Meeting Date 18:58:11 Next meeting on April 13. 18:58:47 See agenda for today, April 6, at https://www.w3.org/events/meetings/402ca109-ea77-4ad0-b088-1ccd8a0f00c5/20230406T120000#agenda 18:58:58 rrsagent, make minutes 18:59:00 I have made the request to generate https://www.w3.org/2023/04/06-aria-at-minutes.html Matt_King 19:00:42 Sam_Shaw has joined #aria-at 19:00:59 jugglinmike has joined #aria-at 19:01:30 Zakim, start the meeting 19:01:30 RRSAgent, make logs Public 19:01:32 please title this meeting ("meeting: ..."), jugglinmike 19:02:27 meeting: ARIA and Assistive Technologies Community Group Weekly Teleconference 19:02:35 present+ jugglinmike 19:02:42 scribe+ jugglinmike 19:02:51 present+ 19:05:43 present+ Matt_King 19:06:15 michael_fairchild has joined #aria-at 19:06:25 present+ 19:06:36 present+ 19:06:38 present+ michael_fairchild 19:09:17 Topic: AT Support Table Launch Update 19:09:53 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 19:10:25 Matt_King: AT support tables are in the main branch and in the preview of the main branch for aria-practices 19:10:35 Matt_King: All the feedback so far is good 19:10:59 Matt_King: They are 99% ready to go. The third topic on the agenda is about the remaining 1% 19:11:34 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 19:11:50 Matt_King: I'm going to put it in Google Docs to share it 19:12:32 Matt_King: I'd like to be able to link to something about PAC's contributions and Bocoup's contributions, on their respective websites 19:13:16 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 19:14:08 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 19:14:51 Matt_King: I still have to meet with Apple and Vispero. Preparing a draft of the blog post was a prerequisite for those meetings 19:15:12 Topic: Current testing check-in 19:15:27 Matt_King: The goal of our current testing is to add more browser/screen reader combinations to the support tables 19:15:45 Matt_King: We can continue to add more, and they'll automatically show up in the APG as we publish them 19:16:00 present+ James_Scholes 19:17:19 James_Scholes: JAWS with Firefox. Command Button all complete with no conflicts same for Toggle Button 19:17:34 James_Scholes: NVDA with Firefox: Command Button all complete with no conflicts same for Toggle Button 19:18:41 James_Scholes: VoiceOver and Safari: Command button--all complete with 2 conflicts. Toggle Button--all complete with 7 conflicts 19:19:02 s/and Safari/and Chrome/ 19:20:36 James_Scholes: I think we need to go through those conflicts and raise issues for the ones we can't resolve 19:23:00 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 19:27:19 Matt_King: Alert Link and Radio, for JAWS and Firefox, NVDA and Firefox, and VoiceOver and Chrome, all need a second tester 19:27:38 present+ Dylan_Sheffer 19:27:58 Dylan_Sheffer: I can take Alert, Link, and Radio for Jaws&Firefox 19:28:09 present+ Alyssa 19:29:05 Alyssa: I can take Alert, Link, and Radio for NVDA&Firefox 19:30:07 JoeHumbert: I can take Alert, Link, and Radio for VoiceOver&Chrome 19:30:54 James_Scholes: Great! Testers: please work on those in alphabetical order (that is: first Alert, then Link, and finally Radio) 19:32:04 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" 19:32:51 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 19:33:41 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) 19:33:56 Topic: Radio plan update for support table launch 19:34:03 Matt_King: JAWS is showing 99% support but it should show 100% 19:34:20 Matt_King: We have reviewed the specific test and command with Vispero and have agreed to remove it 19:34:34 Matt_King: We did remove two instances, but two still remain 19:34:46 We're discussing how to fix this in https://github.com/w3c/aria-at/issues/922 19:35:11 Matt_King: The test itself is valid, it's just that Vispero objected to some commands 19:35:31 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 19:36:13 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) 19:36:26 Matt_King: The discussion to date has been in the issue about the first test 19:37:43 Matt_King: There are two assertions related to the nearby link, and one related to the boundary of the radio group 19:38:02 Matt_King: When you use Tab or Shift+Tab, JAWS doesn't tell you anything about the boundary of the radio group 19:38:27 Matt_King: When we spoke with Vispero, we agreed that the test should not assert anything about the boundary of the radio group 19:39:41 James_Scholes: We removed the assertions from the "interaction mode" tests 19:40:52 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 19:41:08 Matt_King: My suggestion was that we just don't test Tab or Shift+Tab 19:41:45 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. 19:41:59 Matt_King: I described this in my first comment on the issue 19:42:47 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 19:43:30 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 19:44:19 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 19:44:25 Alyssa: that's my take, as well 19:44:50 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 19:50:58 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] 19:51:19 Matt_King: I agree with the second part. We could certainly file an issue to normalize around this. 19:51:28 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. 19:51:55 Alyssa: could the assertion be that you hit the next element? So, for instance, "after you press Tab, it should announce this link"? 19:52:36 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 19:53:02 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. 19:53:37 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 19:55:19 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] 19:56:25 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? 19:57:06 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. 19:57:38 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 19:57:59 James_Scholes: But I don't want to miss the opportunity to acknowledge that we have a significant issue that needs a resolution 19:58:13 James_Scholes: We would like to be able to make changes without needing the entire plan to be re-tested 20:00:41 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" 20:02:45 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 20:04:41 James_Scholes: Do we want to add an assertion which states, "group boundary is NOT conveyed" 20:05:13 Matt_King: I'm concerned about the scope of our testing becoming too granular 20:06:07 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 20:06:58 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. 20:07:16 Matt_King: I think that's where we want to go for all test plans. 20:08:30 James_Scholes: Let's make the change and document our considerations in the pull request 20:08:35 Matt_King: I'm fine with that 20:08:40 michael_fairchild: I'm fine with that, too 20:13:57 Zakim, end the meeting 20:13:57 As of this point the attendees have been Matt_King, jugglinmike, Sam_Shaw, JoeHumbert, michael_fairchild, James_Scholes, Dylan_Sheffer, Alyssa 20:13:59 RRSAgent, please draft minutes 20:14:01 I have made the request to generate https://www.w3.org/2023/04/06-aria-at-minutes.html Zakim 20:14:07 I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent. Goodbye 20:14:07 Zakim has left #aria-at