17:04:15 RRSAgent has joined #aria-at 17:04:19 logging to https://www.w3.org/2023/08/02-aria-at-irc 17:04:19 RRSAgent, make logs Public 17:04:20 please title this meeting ("meeting: ..."), Matt_King 17:04:29 present+ 17:04:38 MEETING: ARIA and Assistive Technologies Community Group 17:04:47 CHAIR: Matt King 17:04:54 rrsagent, make minutes 17:04:56 I have made the request to generate https://www.w3.org/2023/08/02-aria-at-minutes.html Matt_King 17:05:13 Agenda: 1. Discussion of new test writing language to eliminate use of terms "interaction mode" and "reading mode" 2. Data integrity assurance planning 17:05:41 present+ 17:06:17 Agenda #3 Current Testing Status 17:06:46 TOPIC: Current Testing Status 17:07:14 MK: Right now, we dont have any NVDA testing in the queue, only JAWS and Voiceover. Two plans for VO 17:07:42 MK: For JAWS, Hadi has been assigned some test that aren't complete 17:08:06 MK: For VO, only Isabel has been assigned a test 17:08:57 MK: We don't have an additional person assigned for VO Test Plan Actions Action Menu Button Example Using aria-activedescendant 17:09:11 MK: Joe are you able to test that? 17:09:16 JoeHumbert: Yes I can 17:09:58 MK: Alyssa, have you completed everything you were assigned? 17:10:21 present+ Alyssa 17:10:43 Alyssa: Yes, I don't think I've been assigned anything new 17:11:10 MK: Testing updates. All the test plans will be changing in the next couple of months 17:11:51 MK: Right now there are big changes related to the app, mostly test plan admin updates, that will be deployed in the coming weeks. These will help James and I view more clearly what is happening with the working mode process in the app 17:12:55 MK: As we've been working with the Screen reader devs, we've encountered two new issues. 1 as assertion is associated with a command, that the developer doesn't think should be associated with that command. Example navigating with quick keys with JAWS, they believe the output should be different than navigating with arrow keys 17:13:09 MK: In our internal meetings, we've decided we agree 17:15:03 MK: We also think we need a middle set of requirements, to notate assertions the SR should do, but not absolutely necessary Beauvoir 17:15:26 MK: To fix these things requires some big changes, and there are a some knock on problems that are a result 17:16:14 MK: Some of these plans, like the insert up arrow/tab problem, several of the test plans we have already completed, some we anticipate running into soon with the next plans we want to test. 17:16:59 MK: Also, for testing related to mode switching, we now know we will need the mode switch assertions only on some commands 17:17:18 MK: So those are the issues we are currently blocked on 17:17:29 JoeHumbert: Do you have a timeframe as to when the decision will be made? 17:18:11 MK: Yes, I will have a complete project plan proposal for James and I and anyone else to review, done by Monday. I'm spending all my time on this 17:19:16 MK: Then Bocoup will perform some assessments to prioritize the different changes a couple weeks after that. Then we will focus on the P1 issues, I aiming to have some real progress by september, wrapped up by the end of september 17:19:42 JoeHumbert: Okay, when should I aim to have this testing done for Action Menu with VO? 17:20:05 MK: in the next couple weeks would be great 17:20:20 TOPIC: Discussion of new test writing language to eliminate use of terms "interaction mode" and "reading mode" 17:21:35 MK: There are two problems here, both related to VO. Apple insists VO is modeless. Therefor we have all these tests we navigate in reading mode or interaction mode, then we have separate tests for VO that don't mention reading or interaction mode. 17:21:49 MK: This is a problem because essentially each SR has a different set of tests 17:22:29 MK: The other problem, with the current approach, we aren't really testing VO the way VO users use it, with is we don't turn on quick nav 17:22:45 MK: We also use a bunch of commands that aren't commonly used 17:23:05 MK: The bigger problem is having a different set of tests, which causes some confusion with reporting 17:23:17 MK: I've been thinking about how to solve this problem and I have an idea 17:23:27 MK: I'm thinking of ways we can get rid of that wording 17:23:42 MK: I don't have this written up in the issue yet. 17:24:46 MK: One this VO clearly has that seems analogous, is the voiceover curser and keyboard focus. JAWS talks about the virtual cursor and pc cursor, NVDA talks about application focus and browse mode but I think the use the word pointer 17:25:05 MK: NVDA doesn't refer to a cursor 17:25:25 Alyssa: NVDa has a review cursor and object navigation 17:25:30 MK: Thats right! 17:26:08 MK: The goal is to not use SR specific language 17:26:23 MK: So they all talk about cursors. 17:26:54 MK: Here is a proposal. I went through the discloser plan. 17:27:46 Navigate forwards to a collapsed disclosure button in reading mode Move reading cursor forwards to a collapsed disclosure button 17:28:03 MK: That is my proposed wording change to the disclosure plan 17:28:29 JoeHumbert: I'm assuming there will then be less tests? 17:29:14 MK: No same amount of tests, just changing the wording. For VO actually we will end up with twice as many tests but they will be shorter with fewer commands 17:29:28 MK: Right now VO doesn't have a test for moving the curser 17:29:57 MK: If we have the navigate forward to x in reading mode test, that would become move reading cursor forward 17:31:26 MK: This would allow us to use the same test for JAWs and VO. 17:32:20 MK: If we refer to the javascript in in the browser as the application that works, and would work for native applications 17:32:43 MK: So that works well for navigation type commands 17:32:52 MK: I think that also works with any SR 17:33:36 MK: So we have four general categories of commands: Navigation, reading, operation, Those are 3 main ones, then some miscellaneous ones like dismiss 17:33:44 MK: Now for the reading ones 17:33:52 MK: These are trickier 17:34:25 MK: We currently have commands in two tests, read info about button in reading and read info about button in interaction mode 17:34:38 MK: Borrowing from the VO test, it has language that says 17:35:10 describe the element in the reading cursor, and describe element with keyboard focus 17:35:26 MK: We say read info about button in reading mode, or read info in interaction mode 17:35:33 MK: For reading mode 17:35:40 MK: Let me know what sounds good 17:35:50 MK: Read info about a button in reading cursor 17:36:02 MK: request info about a button in reading cursor 17:36:09 MK: Describe button in reading cursor 17:36:27 MK: Interrogate a button in a reading cursor 17:36:42 Alyssa: I feel like request would be fine, thats what you are doing 17:36:46 MK: Thats correct 17:37:03 MK: Yeah thats what I was wondering if someone would interpret that that way 17:37:19 MK: What do you think Joe? 17:37:32 JoeHumbert: I agree with Alyssa 17:37:55 Alyssa: Interrogate could be fun! 17:38:47 MK: You say insert tab is requesting info about it. If in a grid, JAWS has a command to give you row and column info, so it would have a different assertion but still asks the same request to info about where you are 17:39:12 MK: Then you don't need a separate test for row and column 17:39:26 MK: You could have one test with many assertions 17:40:05 MK: So when it came to the application cursor, I said request info about a button with application focus 17:40:31 MK: We are kinda saying request info about a button that has application focus, but instead to shorten it I has with application focus 17:40:55 MK: In VO the cursor is a box visually 17:42:24 MK: Alot of times in our documentation we talk about focus, but what we really mean is the cursor 17:43:00 MK: We could say with reading cursor focus instead of with cursor focus 17:43:34 Request information about a collapsed disclosure button with reading cursor focus 17:44:07 MK: I think I will go with that for the proposal 17:44:42 MK: I think thats a good discussion about reading and requesting info in ways of working 17:44:51 MK: The next set of commands relates to operating 17:45:15 MK: We current have "operate a collapsed disclosure button in reading mode" 17:45:19 MK: My proposal is 17:45:51 MK: " Use reading cursor function to operate a collapse disclosure function" 17:46:00 Alyssa: That is very clear to me 17:47:20 MK: Then the interaction mode version " operate a collapse disclosure function in function mode" would become "use application functions to operate..." 17:48:42 MK: It seems when I apply that wording in operating, replacing operating mode with application function and reading mode with cursor functions it works well 17:50:48 MK: Here's one I haven't figured out yet "Dismiss dropdown in reading mode" 17:50:59 Alyssa "dismiss a dropdown with reading cursor active" 17:51:24 MK: If we do that, then what would be the application version? With VO the reading cursor is always active 17:51:57 MK: "Use reading cursor functions to dismiss a dropdown" 17:52:19 MK: I need to review the purpose of this test though I'm not sure this is the focus 17:52:38 MK: This might also be a case of examining "Do we want this test?" 17:53:11 MK: I will need to review this test 17:53:54 MK: "Use application function to activate a link in the drop down" 17:54:08 MK: The only that seems a little suspect to me is the dismiss one 17:54:18 MK: So this is some good feedback 17:55:03 MK: I'm actually hoping the tests become easier to read. We also need to increase the readability of the tests, so having clearly worded tests will effect how clear the reports are 17:55:21 MK: Okay this will be in an issue 17:55:35 MK: Anyone else have thoughts to what to watch out for? 17:56:38 JoeHumbert: Just be consistent and not choosing new terminology all over the place. So that its easy to jump between test for one AT and tests for another to clearly understand the direction 17:57:33 MK: I hoping that all desktop SR would have the exact same tests with the same words, just the list of commands and assertions may vary. 17:58:08 MK: We currently provide translation " How do you turn off the reading cursor" 17:59:02 MK: This will create some tests we need to rerun but I think we can handle it 17:59:20 MK: Thanks everyone, good discussion. Next weeks meeting is on Thursday 17:59:52 MK: We might be able to skip a meeting next week, I will discuss with James. I think with the state of the test queue and all the work on the application we may not need a meeting 18:00:22 rrsagent, make minutes 18:00:53 I have made the request to generate https://www.w3.org/2023/08/02-aria-at-minutes.html Matt_King 19:34:42 Zakim has left #aria-at