19:00:41 <RRSAgent> RRSAgent has joined #aria-at
19:00:41 <RRSAgent> logging to https://www.w3.org/2022/05/09-aria-at-irc
19:00:50 <s3ththompson> MEETING: ARIA and Assistive Technologies Community Group
19:00:57 <s3ththompson> CHAIR: Michael Fairchild
19:01:05 <s3ththompson> SCRIBE: s3ththompson
19:01:05 <s3ththompson> present+
19:01:07 <s3ththompson> rrsagent, make minutes
19:01:07 <RRSAgent> I have made the request to generate https://www.w3.org/2022/05/09-aria-at-minutes.html s3ththompson
19:01:11 <s3ththompson> rrsagent, make log public
19:01:33 <zcorpan> zcorpan has joined #aria-at
19:02:07 <zcorpan> present+
19:02:08 <Sam> Sam has joined #aria-at
19:02:12 <cmumford> cmumford has joined #aria-at
19:02:22 <Sam> present+
19:05:56 <michael_fairchild> michael_fairchild has joined #aria-at
19:06:15 <s3ththompson> TOPIC: Instructions
19:06:16 <zcorpan> https://github.com/w3c/aria-at-automation/issues/15
19:06:23 <s3ththompson> TOPIC: Introduction
19:06:28 <michael_fairchild> present+
19:06:51 <s3ththompson> zcorpan: roadmap is in w3c/aria-at-automation#15
19:07:31 <s3ththompson> zcorpan: we subdivided our roadmap into 0 (protocol), 1 (settings), 2 (spoken output), 3 (simulating keypresses), 4 (activating certain commands)
19:07:36 <zcorpan> https://github.com/w3c/aria-at-automation/pull/19
19:08:16 <s3ththompson> zcorpan: in w3c/aria-at-automation#19 i started a draft of the protocol, borrowing heavily from WebDriver BiDi spec
19:09:11 <s3ththompson> present+ jugglinmike
19:09:38 <s3ththompson> present+ Glen Gordon
19:09:48 <s3ththompson> present+ Michael Fairchild
19:09:58 <s3ththompson> present+ Matt_King
19:10:10 <s3ththompson> present+ cmumford
19:12:56 <s3ththompson> present+ Joshua Bruning
19:13:27 <s3ththompson> present+ David-Emmanuel Divernois
19:13:49 <s3ththompson> present+ Aaron Leventhal
19:13:59 <s3ththompson> present+ mzgoddard
19:14:06 <s3ththompson> present+ James Scholes
19:15:07 <s3ththompson> s3ththompson: the benefit of the WebDriver BiDi spec is that it is an existing protocol that has been heavily discussed... and also, it's generic enough in its description that it's not *too* prescriptive. there is enough flexibility for us to adapt to our needs for screen readers
19:16:14 <s3ththompson> Matt_King: i'm curious about the bi-directional / async nature of the protocol and the idea that the request has an ID that the response returns (to connect the two together). how do we know which outputs from the screen reader have the id that gets associated with the original request?
19:17:08 <s3ththompson> zcorpan: It's not necessarily that the spoken output is the "response". it could be that the "response" was "the command was accepted" and then there would be a separate event that triggers the spoken output
19:18:42 <s3ththompson> zcorpan: it's possible that the test writer would issue certain commands and then wait for a certain amount of time for the response
19:19:00 <s3ththompson> s3ththompson: also the case that the screen reader could issue a log event or another protocol event that says "i spoke something", etc.
19:19:15 <s3ththompson> David-Emmanuel Divernois: what is the concept of a session with this protocol?
19:19:27 <s3ththompson> David-Emmanuel Divernois: is it related to the concept of a browser session?
19:19:53 <s3ththompson> zcorpan: as it's written right now, it's a separate concept of a session (and a separate connection)
19:20:41 <s3ththompson> zcorpan: it could be possible to extend WebDriver BiDi instead of creating a new protocol... (which also means you would request a browser/screen reader at one time) but we would have to discuss that
19:21:17 <aaronlev> aaronlev has joined #aria-at
19:21:43 <s3ththompson> Matt_King: but you would want to be able to use the Automation API separately from the browser right?
19:22:16 <s3ththompson> s3ththompson: yeah, i think it makes more sense to be a complementary protocol rather than an extension (and we could always build tools on top to facilitate)
19:22:28 <joshbruning> joshbruning has joined #aria-at
19:22:45 <s3ththompson> David-Emmanuel Divernois: so right now these protocols are independent
19:23:14 <s3ththompson> zcorpan: yes, right now we think you would use both AT Driver and WebDriver
19:24:23 <s3ththompson> David-Emmanuel Divernois: I think it could be confusing if there are different types of sessions across browsers / ATs (how do they relate to each other, etc.)
19:26:01 <s3ththompson> James Scholes: i think this is up to the tooling layer to solve, because most users are using playwright instead of webdriver
19:28:56 <s3ththompson> Glen Gordon: as long as you only have one client of the protocol at one time it's fine... if you have multiple clients and you send unsolicited output, there would need to be a way to know what you're sending to
19:31:26 <s3ththompson> Joshua Bruning: the screen reader user is going to want to troubleshoot this locally... they need to figure out how to debug the session with another instance of the screenreader
19:32:25 <s3ththompson> s3ththompson: sessions are still new territory for screen readers. we're in the process of figuring out what they look like, but we don't necessarily have to solve all of that right away. the spec just says the protocol should work with "1 or more session"
19:34:01 <s3ththompson> mzgoddard: sessions are definitely broader than just the web browser... there are other analogs we can look to
19:35:23 <s3ththompson> James Scholes: just to be pragmatic here, we definitely have some really big problems with running two screen readers at one time... because screen reader operating model is fundamentally different than browser
19:36:47 <s3ththompson> mzgoddard: keep the protocl flexible w.r.t. sessions... the screen readers could even be on different machines
19:39:06 <s3ththompson> jugglinmike: i do think we're missing some input from sauce labs / brwoserstack type of providers. as a web developer one of the nice parts of webdriver is that my code can either run on my machine or in the cloud, just by changing a URL
19:41:58 <s3ththompson> James Scholes: i agree... and i think as long as the protocol allows for that flexibility, it shouldn't need to necessarily prescribe it
19:42:45 <s3ththompson> jugglinmike: i think it's just on us to make sure that the handshake is information rich
19:44:06 <s3ththompson> zcorpan: sounds like one new use case there: Assuming you want to test screen reader and browser together, you would need a way to describe which browser session you want
19:45:06 <s3ththompson> James Scholes: before we answer that question, i think we need to think about 2 audiences: the developer audience and the experience of whoever is setting up the remote end
19:51:32 <s3ththompson> s3ththompson: next steps: it sounds like we have directional agreement on the protocol
19:52:18 <s3ththompson> s3ththompson: the next steps will be to test a "hello world" of sorts by standardizing a simple command and testing out sending this command across the protocol (e.g. "what version is runinng). james and his team will be working on implementing this
19:52:29 <s3ththompson> s3ththompson: then we will proceed to milestone 1 of the roadmap (settings)
19:52:39 <s3ththompson> Glen Gordon: I think we've started with the easiest thing! (laughs)f
19:53:20 <s3ththompson> Glen Gordon: have we considered how the browser is controlled? is it controlled separately? or will AT driver control the browser
19:54:54 <s3ththompson> mzgoddard: I think it would be possible to do it either way (you could have the AT open a web browser), but it might also be more streamlined to just use a dedicated tool like webdriver
19:55:45 <s3ththompson> zcorpan: one thing that just occurred to me is: which connection would you set up first? since you can have multiple webdriver sessions on one host, but only one screenreader... maybe the AT connection should be first
19:56:10 <s3ththompson> James Scholes: that's sensible... even during screen reader testing, it's advised to start the screen reader first before starting the web browser
19:56:19 <s3ththompson> zcorpan: interesting, okay
19:56:44 <s3ththompson> zcorpan: we would have to extend WebDriver then to understand the AT
19:57:25 <s3ththompson> jugglinmike: that might be more of a medium term solution rather than a short term one... webdriver has a built-in extension method to do exactly this kind of thing
19:58:11 <s3ththompson> zcorpan: it's also worth noting that we can borrow that extensibility for AT Driver
19:59:04 <s3ththompson> James Scholes: I think it's important if possible that we try to stay as true to the underlying spec as possible so that we can use existing tools wherever possible... for example right now you could use our new AT spec and then literally any other existing tool to start the web browser
20:06:48 <s3ththompson> rrsagent, make minutes
20:06:48 <RRSAgent> I have made the request to generate https://www.w3.org/2022/05/09-aria-at-minutes.html s3ththompson