19:52:06 RRSAgent has joined #aria-at 19:52:06 logging to https://www.w3.org/2021/03/04-aria-at-irc 19:52:21 rrsagent, make log public 19:52:37 MEETING: ARIA and Assistive Technologies Community Group 19:52:52 CHAIR: James Schoels 19:52:59 present+ 19:53:05 rrsagent, make minutes 19:53:05 I have made the request to generate https://www.w3.org/2021/03/04-aria-at-minutes.html Matt_King 19:54:57 zakim, clear agenda 19:54:57 agenda cleared 19:58:17 michael_fairchild has joined #aria-at 20:00:45 https://bocoup.com/blog/how-to-scribe-at-tpac 20:01:30 jscholes has joined #aria-at 20:02:29 jongund has joined #aria-at 20:04:59 present+ IsaDC 20:07:37 TOPIC: Issue 369 - Setup scripts 20:07:51 github topic: https://github.com/w3c/aria-at/issues/369 20:10:22 js: Want to talk about both how written and used by testers 20:10:46 How will it interact with the apg examples, e.g., scroll an option into view 20:10:47 rob-fentress has joined #aria-at 20:11:07 ideally, want to reuse individual bits of logic when multiple tests use the same bit of logic 20:12:21 This could require modifying apg examples to be controlled by script. 20:12:35 Look at select only combobox as example. 20:13:52 The apg combox scripts looks for all comboboxes on page, but aria-at setup scripts modifies that to look for one. 20:14:01 +present 20:14:13 present+ 20:15:27 present+ 20:16:35 The issues is that the APG JS encapsulates the combobox object, so we can access it from a setup script; it is not global. 20:17:13 Then we can not access that object to select a specific item in the combobox dropdown. the JS from APG has amethod for doing that, but we can't access it. 20:18:58 We want to re-used the methods that has ben developed by APG. 20:19:27 Sina: what is ideal aopproach? 20:19:46 js: Every APG example stores its entry point 20:19:53 or entry points 20:20:15 so a calling script can access that functionality. 20:23:54 Sina: Can we define a global entry point, like an interface, for the examples that that are instantiated as a class 20:24:58 Sina: define a function that you can always call, e.g., driveable, 20:25:27 js: If there was a property on the window object, e.g., APG, and that is the controller for the example code 20:28:19 MK: James, can you create an issue in APG that defines what you need. 20:34:00 mk: This will address avoiding aria-at modification to apg js, but not to html. we should take up automation of apg html as part of apg redesign project. 20:34:45 js: Now, let's discuss how to chain scripts together and how testers run setup scripts 20:35:24 js: on chaining, it's on me to write up that for bocoup and determine how they want to solve 20:36:03 js: For testers, it would seem that we want a button on the page for them to execute the script instead of running it on page load. 20:36:21 this brings up the possible need for a tare down after the test 20:36:50 Say for example, say the test is testing checkbox and the box is not checked 20:36:55 the tester checks it 20:37:03 now it is not in the right starting state. 20:37:35 mf: What if we replace that button with a reset button that reloads the page. 20:37:56 then after reset reloads, the button becomes run setup 20:40:54 sina: +1 to that ida 20:41:09 s/ida/idea/ 20:43:22 mf: what happens when the button name changes from run setup to reset? need to avoid scren reader side effects. 20:44:08 js: when we can control that by how we sequence the events in the setup script. we will only change the name of the button, not make a new one. then we will intentionally set focus where we want in the example. 20:44:27 js: what about error handling? what if setup script fails? 20:45:08 mf: could fail in multiple ways. we might not have failures that result in a known state that we can handle. 20:46:39 mk: I think it should be up to humans to understand if tthe setup script didn't do what is supposed to do 20:49:14 TOPIC: Issue 300- track status of a test 20:49:32 js: this is on Bocoup to add a flag to a test 20:50:41 mk: we have to decide whether or not we have the status on the test itself be something distinct from the status of the test results 20:51:37 mk: if you think of our workflow as a single sequence, where we have one deliverable that is the test and results. Alternatively we could say that the test is one deliverable and the results are a different deliverable. 20:52:16 js: should the tests be versioned? 20:52:23 mk: I don't know 20:55:24 js: how would we respond to changes to assistive technologies? For example would there ever be a case where a new version of NVDA invalidates our assertions? 20:56:40 mk: yes, there could, and they would need to raise an issue with us 20:57:14 js: that means we would need to maintain the previous version of that assertions so that we can still publish our previous results. 20:59:51 js: can we do this incrementally, maybe not implement versioning initially? 20:59:57 mk: possibly yes 21:00:40 mk: think it is good idea to know where we would be going in terms of asolution so we get the status on the correct object in the data model 21:00:46 rrsagent, make minutes 21:00:46 I have made the request to generate https://www.w3.org/2021/03/04-aria-at-minutes.html Matt_King 21:34:24 zakim, bye 21:34:24 leaving. As of this point the attendees have been Matt_King, zcorpan, boazsender, michael_fairchild, s3ththompson, weston, Sina, jongund, jscholes, hadi, IsaDC, present, 21:34:24 Zakim has left #aria-at 21:34:41 rrsagent, make minutes 21:34:41 I have made the request to generate https://www.w3.org/2021/03/04-aria-at-minutes.html Matt_King