19:01:45 <RRSAgent> RRSAgent has joined #aria-at
19:01:45 <RRSAgent> logging to https://www.w3.org/2022/03/14-aria-at-irc
19:01:56 <Zakim> Zakim has joined #aria-at
19:01:56 <Travis> Present+ Travis_Leithead
19:02:08 <Lauriat> Present+
19:02:17 <mzgoddard> mzgoddard has joined #aria-at
19:02:21 <s3ththompson> rrsagent, make notes
19:02:21 <RRSAgent> I'm logging. I don't understand 'make notes', s3ththompson.  Try /msg RRSAgent help
19:02:27 <s3ththompson> rrsagent, make minutes
19:02:27 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/14-aria-at-minutes.html s3ththompson
19:02:30 <s3ththompson> rrsagent, make log public
19:02:32 <s3ththompson> SCRIBE: s3ththompson
19:06:12 <s3ththompson> present+ Steven Lambert
19:06:41 <s3ththompson> present+ James Craig
19:06:47 <zcorpan> present+
19:07:44 <s3ththompson> present+ Matt_King
19:08:11 <s3ththompson> present+ Cameron Cundiff
19:09:35 <s3ththompson> present+ James Scholes
19:10:05 <s3ththompson> present+ Harris Schneiderman
19:10:25 <s3ththompson> present+ Cynthia Shelly
19:20:02 <s3ththompson> Topic: History & Overview
19:22:00 <s3ththompson> We've started with ARIA-AT CG work doing interoperability testing.
19:22:00 <s3ththompson> How do W3C Standards work?
19:22:00 <s3ththompson> Need a venue, under the ARIA-AT CG umbrella now, but there are other relevant groups, like BTT WG, and maybe AT Automation becomes its own group in future?
19:22:00 <s3ththompson> Start with a draft explainer that encapsulates the scope of the project
19:22:00 <s3ththompson> Need implementation experience
19:22:02 <s3ththompson> Standard develops in parallel with implementation experience, as much as the other way around
19:22:15 <s3ththompson> present+ Glen Gordon
19:22:29 <s3ththompson> Glen Gordon: Are we coming in at an early stage or has something already been written?
19:22:31 <Travis> Link to the explainer here?
19:22:43 <s3ththompson> https://github.com/w3c/aria-at-automation
19:22:52 <Travis> 👍
19:23:22 <s3ththompson> Matt_King: we are coming in at an early stage, we've just done research and r&d to make sure that we're able to have informed conversation
19:25:07 <aaronlev> aaronlev has joined #aria-at
19:25:26 <s3ththompson> James Craig: I have a few points I wanted to add to make sure they're covered: 1) lots of precedence around work that Joanie from Igalia did in the past. might want to involve them and make sure we look at precedence 2) there is already some precedence around changing settings programmatically that comes from work that was done to enable restoring sessions
19:25:28 <cyns> cyns has joined #aria-at
19:25:37 <s3ththompson> James Craig: 3) Want to make sure we cover security from an early stage, because there are lots of tricky parts to that
19:25:59 <s3ththompson> TOPIC: Goals for AT Automation Standard
19:26:34 <s3ththompson> recitation of goals from draft explainer: https://github.com/w3c/aria-at-automation#goals
19:27:31 <s3ththompson> Cameron Cundiff: are we trying to test screen readers by capturing output? or are we trying to just test adherence to existing accessibility APIs
19:28:24 <s3ththompson> zcorpan: this project is more about testing ATs themselves, but it could be complemented by testing other parts of the accessibility stack
19:29:11 <s3ththompson> Matt_King: there are other projects, like the accessibility object model (AOM) that would do more of what you're asking. This isn't that... this is about ensuring that the screen reader experience that you see today doesn't regress in some way
19:29:49 <s3ththompson> Matt_King: the primary goal here is to test screen reader behavior itself. we're trying to ensure screen reader and browser (and interaction between the two) hasn't changed that would break expectations
19:30:24 <s3ththompson> Matt_King: James, should your concerns about security / privacy be framed as a goal?
19:30:58 <s3ththompson> James Craig: I think that would be helpful. VoiceOver and other AT products, for example, have greater access to the system than other long-running apps (e.g. access to login screen)
19:32:11 <s3ththompson> James Craig: there are some context in, e.g. XCode developer tools, where app developers can run a variety of automation tools on their own app... but it's limited to that tool. In addition to that, the aspect of XSS (cross-site scripting) could be a risk... effectively using a screen reader which might have access to run in a browser with multiple tabs to enable XSS
19:32:48 <s3ththompson> James Craig: those issues have limited the ability to ship developer friendly tooling in the past, so i think it would be good to capture as a goal to make sure others are aware and thinking about it
19:33:38 <s3ththompson> zcorpan: Is the XSS-esque security concern something that WebDriver already exposes?
19:34:08 <s3ththompson> James Craig: I think maybe we could set up some sort of sandboxing framework?
19:35:52 <s3ththompson> Seth Thompson: maybe this question is related to the question of a testing "session"?
19:36:41 <s3ththompson> James Craig: might also be useful framing this in terms of user expectations of explicitly invoking tools for a specific purpose in a safe and privacy-friendly manner
19:37:45 <s3ththompson> Cameron Cundiff: recently Circle CI and GitHub CI disabled SIP in their CI environments. i don't know that they know the implications there, but it is likely that that's a vector for security issues
19:38:32 <s3ththompson> (when System Integrity Protection, or SIP, is disabled, it's possible to programatically turn on VoiceOver.  Not recommended to turn it off in production)
19:39:16 <s3ththompson> https://github.com/actions/virtual-environments/issues/4770
19:39:43 <s3ththompson> Glen Gordon: from JAWS side, this would never be on-by-default... would need setting or certificate or something to protect the average user
19:42:40 <s3ththompson> another open question has to do with whether the API should include simulating key presses
19:43:27 <s3ththompson> James Craig: if you're talking about OS / HID-level, that's a big security risk
19:44:16 <s3ththompson> James Craig: also, are we limiting to screen readers, or would this apply to something like a switch control too?
19:46:24 <s3ththompson> James Scholes: to me, I'm also interested in testing alternative gestures or input devices. so to me, the API should perhaps trigger a "simulated" input type, e.g. "please react *as if* this was the right-swipe gesture on a trackpad"
19:49:38 <s3ththompson> s3ththompson: the question about OS-keypresses has more to do with asking: "does a simulated keypress make sense in the context of an API that is implemented by the screen reader"
19:49:54 <s3ththompson> Glen Gorder: for JAWS, there is a dance where we "eat" the keypress and then re-emit it
19:50:58 <s3ththompson> Glen Gorder: there's a danger in passing on keypresses to the screen reader, because the system may be in a state where it is "eating" a key because it's in some sort of virtual mode, but in fact in reality that key should have gone to the browser
19:52:05 <s3ththompson> Glen Gorder: the above was only for keys attached to JAWS script... so doesn't apply to alphanumeric keys
20:01:28 <s3ththompson> Aaron Leventhal: i'd like to use this API to test the Chrome UI itself... so i'd like to ensure that the input method is as close to keyboard that user would type as possible
20:01:37 <s3ththompson> s3ththompson: I think we'll do monthly meetings going forward
20:01:58 <s3ththompson> but try to continue conversations over github issues going forward
20:02:48 <s3ththompson> s3ththompson: in the meantime, please use join the Community Group and mailing list at https://www.w3.org/community/aria-at/
20:07:23 <s3ththompson> Backup of the chat log
20:07:42 <s3ththompson> zoom chat log https://www.irccloud.com/pastebin/ziHYv45F/zoom_chat_log.txt
20:10:38 <s3ththompson> rrsagent, make minutes
20:10:38 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/14-aria-at-minutes.html s3ththompson