Meeting minutes
Instructions
<zcorpan> https://
Introduction
zcorpan: roadmap is in w3c/aria-at-automation#15
zcorpan: we subdivided our roadmap into 0 (protocol), 1 (settings), 2 (spoken output), 3 (simulating keypresses), 4 (activating certain commands)
<zcorpan> https://
zcorpan: in w3c/aria-at-automation#19 i started a draft of the protocol, borrowing heavily from WebDriver BiDi spec
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
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?
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
zcorpan: it's possible that the test writer would issue certain commands and then wait for a certain amount of time for the response
s3ththompson: also the case that the screen reader could issue a log event or another protocol event that says "i spoke something", etc.
David-Emmanuel Divernois: what is the concept of a session with this protocol?
David-Emmanuel Divernois: is it related to the concept of a browser session?
zcorpan: as it's written right now, it's a separate concept of a session (and a separate connection)
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
Matt_King: but you would want to be able to use the Automation API separately from the browser right?
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)
David-Emmanuel Divernois: so right now these protocols are independent
zcorpan: yes, right now we think you would use both AT Driver and WebDriver
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.)
James Scholes: i think this is up to the tooling layer to solve, because most users are using playwright instead of webdriver
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
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
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"
mzgoddard: sessions are definitely broader than just the web browser... there are other analogs we can look to
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
mzgoddard: keep the protocl flexible w.r.t. sessions... the screen readers could even be on different machines
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
James Scholes: i agree... and i think as long as the protocol allows for that flexibility, it shouldn't need to necessarily prescribe it
jugglinmike: i think it's just on us to make sure that the handshake is information rich
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
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
s3ththompson: next steps: it sounds like we have directional agreement on the protocol
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
s3ththompson: then we will proceed to milestone 1 of the roadmap (settings)
Glen Gordon: I think we've started with the easiest thing! (laughs)f
Glen Gordon: have we considered how the browser is controlled? is it controlled separately? or will AT driver control the browser
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
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
James Scholes: that's sensible... even during screen reader testing, it's advised to start the screen reader first before starting the web browser
zcorpan: interesting, okay
zcorpan: we would have to extend WebDriver then to understand the AT
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
zcorpan: it's also worth noting that we can borrow that extensibility for AT Driver
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