18:05:03 <RRSAgent> RRSAgent has joined #aria-at
18:05:03 <RRSAgent> logging to https://www.w3.org/2022/07/07-aria-at-irc
18:05:27 <s3ththompson> MEETING: ARIA-AT Automation and Community Group Meetings
18:05:30 <s3ththompson> rrsagent, make minutes
18:05:30 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/07-aria-at-minutes.html s3ththompson
18:05:41 <s3ththompson> present+
18:05:46 <s3ththompson> SCRIBE: s3ththompson
18:05:59 <michael_fairchild> michael_fairchild has joined #aria-at
18:06:04 <michael_fairchild> present+
18:06:05 <zcorpan> RRSAgent, make logs public
18:06:07 <zcorpan> present+
18:06:12 <s3ththompson> TOPIC: Update on the API Standard
18:06:34 <Rich_Noah> Rich_Noah has joined #aria-at
18:06:44 <mzgoddard> mzgoddard has joined #aria-at
18:06:46 <mzgoddard> +present
18:06:51 <Rich_Noah> present+
18:07:02 <s3ththompson> zcorpan: have been working on AT driver spec. there are 4 PRs open
18:07:05 <zcorpan> https://github.com/w3c/aria-at-automation/issues/15
18:10:29 <s3ththompson> two new PRs since last time: capture output and simulate keypresses
18:11:22 <s3ththompson> zcorpan: simulate keypresses adds two different types of events "keypress" which is a high-level command and "keyup" and "keydown" which is a lower-level command
18:13:07 <s3ththompson> James Scholes: what if implementation only supports keypress level of granularity
18:13:44 <s3ththompson> zcorpan: i guess the idea would be to require the low-level access for better fidelity of simulation by the user... but if it's not implementable than obviously we will have to work around or revisit that idea
18:14:15 <s3ththompson> James Scholes: we were hoping to use the built-in NVDA support for simulating keypresses which don't break things down like that...
18:15:24 <s3ththompson> mzgoddard: what types of use cases do we need to consider? do ATs respond to keys being held down for X seconds? do they respond to key being pressed in quick succession? How do ATs respond to one key being held down while other keys are also pressed
18:15:39 <s3ththompson> James Scholes: i'm not sure about the first, but the second and third use cases are definitely common
18:16:17 <s3ththompson> James Scholes: there is also a 4th category used by JAWS (but not NVDA) which is pressing JAWS key with space + the next key you press is handled by JAWS. a way to prevent that next key from being sent to the application
18:18:19 <s3ththompson> James Scholes: i can look at the code to see if we have other options here, but basically you construct a "gesture" and then call a "send" method on it
18:20:52 <s3ththompson> zcorpan: webdriver uses sendkeys, a command that takes an "element" parameter. it's intended to only work for elements that accept text input in a browser (something that's content editable)
18:21:10 <s3ththompson> James Scholes: overall, it will be extremely common to need to type keyboard shortcuts
18:21:30 <s3ththompson> jugglinmike: the other thing that sendkeys abstracts away is the specific duration between key presses.
18:27:43 <s3ththompson> mzgoddard: maybe we instead approach this by making sure we can extend it in the future if needed
18:30:20 <s3ththompson> jugglinmike: in terms of future proofing, having just keypress doesn't preclude dropping down to keyup / keydown later
18:31:53 <s3ththompson> James Scholes: for us, if we need to support keyup / keydown we can definitely investigate that path
18:31:58 <s3ththompson> James Scholes: in the future we will probably need touch gestures and eventually braille displays... i
18:32:25 <s3ththompson> James Scholes: for now though, we will need a way to send multiple keystrokes in succession. we can't rely on the network to deliver two keystrokes in succession
18:32:48 <s3ththompson> James Scholes: can we have the ability to send multiple keystrokes together to make sure that successive keystrokes are interpreted together before a timeout period?
18:33:47 <s3ththompson> zcorpan: i think in webdriver, "pause" is an action, so you can send "keydown", "pause for 1 second", and then "keyup"
18:35:05 <s3ththompson> James Scholes: at a minimum, we're saying we want a "pause" action, and definitely a "keypress" action, that supports modifier keys
18:36:53 <s3ththompson> zcorpan: if we need "keyup" / "keydown" in the future, we'll just add them then
18:39:10 <s3ththompson> s3ththompson: so the "keypress" action needs to handle one or more keys?
18:39:51 <s3ththompson> James Scholes: but with the additional stipulation that JAWS / NVDA have special modifier keys called the JAWS key or the NVDA key
18:54:12 <s3ththompson> jugglinmike / James Scholes: discussion about the internals of NVDA key simulation (the low-level code is part of one method that they would like to use, rather than rewrite or breakup)
18:54:29 <s3ththompson> michael_fairchild: does the spec prescribe how keypresses are simulated?
18:54:44 <s3ththompson> zcorpan: there isn't anything spec'd on the remote end side
18:57:22 <Joe_Humbert> Joe_Humbert has joined #aria-at
18:58:58 <Sam_at_PAC> Sam_at_PAC has joined #aria-at
18:59:06 <s3ththompson> michael_fairchild: do we need to call out that we can pass through keys? that essentially with these apis, you could also drive the browser, etc.
19:00:47 <s3ththompson> mzgoddard: perhaps how we pass them through is defined by the AT...
19:02:14 <Matt_King> Matt_King has joined #aria-at
19:04:45 <isaacdurazo> isaacdurazo has joined #aria-at
19:07:22 <Matt_King> TOPIC: Start of agend for Community Group Meeting
19:07:58 <Matt_King> TOPIC: Meeting next weeks\
19:08:13 <zcorpan> RRSAgent: make minutes
19:08:13 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/07-aria-at-minutes.html zcorpan
19:10:28 <zcorpan> RRSAgent, start a new log
19:11:17 <Matt_King> MK: Should we meet on july 14 and/or july 21
19:13:51 <Matt_King> Next community group meeting will be July 28
19:14:21 <Matt_King> TOPIC: Unblocking progress on first 8 plans to be sent to vispero and apple
19:14:31 <Matt_King> present+
19:14:36 <Matt_King> present+ James
19:14:46 <Joe_Humbert> present+
19:15:42 <Matt_King> James: as we know we are working on a new experience in the app for sr devs
19:16:13 <Matt_King> for now plan  is to create an issue for a vendor's review of a given plan, e.g., apple review of toggle button.
19:16:53 <Matt_King> James will send email to each vendor telling them bout the plans ready for review with links to review issues and plans.
19:17:07 <Matt_King> They will get a link to the report page for a test plan
19:17:59 <Matt_King> One problem is that we can't publish in a candidate state
19:18:40 <Matt_King> That means we have to mark a plan as finalized to give it to the vendor.
19:20:28 <s3ththompson> Matt_King: so James, i think there might be some confusion on wording. that button is called finalize, but actually what we're publishing is something with a warning label. it's not actually finalized. (we didn't call it candidate but we called it that inside of the description).
20:14:25 <Matt_King> rrsagent, make minutes
20:14:25 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/07-aria-at-minutes.html Matt_King
20:28:54 <Matt_King> scribe: matt_king
20:29:45 <Matt_King> Matt: All the data on the reports page has a warning that says it is from candidate test plans, not from recommended test plans.
20:30:21 <Matt_King> Unfortunately, the button labeled finalize is not labeled the way we would like. It was labeled before the 2021 working mode updates.
20:30:47 <Matt_King> So, pressing finalize and publishing actually puts a candidate test plan report on to the reports page.
20:31:21 <Matt_King> That will have to change soon. The UI in teh app needs to catch up with the 2021 working mode changes.
20:31:58 <Matt_King> Knowing this, does that unblock progress with the first 8 plans and enable ou to send them to the screen reader devs?
20:32:16 <Matt_King> James: OK, we can move forward with that.
20:32:46 <Matt_King> Weare letting them know that this is not the final UI; it is a work in progress and we will support them through the process.
20:33:20 <Matt_King> Seth: We didn't know the process would be moving forward without the new screen reader UX.
20:34:05 <Matt_King> AALL: Discussion of how to keep the working mode process moving while developing the new review experience.
20:34:41 <Matt_King> There have been some misunderstandings about time table and dependencies.
20:35:43 <Matt_King> TOPIC: Plans for new candidate review experience
20:36:12 <Matt_King> Isaac is working on additional changes to design that should be ready by end of next week.
20:36:38 <Matt_King> Bocoup is not working on this project during week of July 18 due to all-hands meetings that week.
20:37:07 <Matt_King> Community group members can provide feedback on Isaac's design during the week of July 18 via GitHub.
20:37:51 <Matt_King> We believe the design is mature enough that async feedback and discussion will likely suffice.
20:38:02 <Matt_King> Build could start during week of July 25.
20:38:33 <Matt_King> Discussed building only a presentation experience that walks users through the test plan in much the same way as the test runner.
20:39:04 <Matt_King> Then, after building the presentation and getting feedback on it, adding the buttons for actions, such as raising issues and marking approval.
20:39:26 <Matt_King> TOPIC: App performance
20:40:09 <Matt_King> Updates that significantly improve performance re launched, but these do not yet get perf to what the eng team considers acceptable.
20:40:36 <Matt_King> Seth is still working on plans for additional perf improvement and will share next week.
20:40:43 <Matt_King> This is a apriority for the team.
20:40:50 <Matt_King> rrsagent, make minutes
20:40:50 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/07-aria-at-minutes.html Matt_King