Meeting minutes
Interesting Open Source Precedent
westont: found something called Assistive Webdriver that might be very relevant https://
westont: they appear to be doing something similar to what we're doing
michael fairchild: it looks like you have to use a VM to test and that's how they handle keyboard capturing as well
westont: it looks like they have audio from the TTS off, but you can turn it off
<westont> david-emmanuel.divernois@amadeus.com is the primary dev on it (was tough to track down his email)
westont: looks like they also use this to test their design pattern library. biggest example i've seen so far
<westont> Here's an example of one of their production tests (doesn't use Assistive-Webdriver, but the same tech/architecture): https://
<westont> https://
Automation API Standard Proposal - Next steps
s3ththompson: when should we share the Automation API with a broader audience?
zcorpan: very few changes, but we did address feedback from CG group last week
zcorpan: feedback was addressed in https://
s3ththompson: Mike will keyboard signal handling impact API Standard Proposal?
Mike: probably
Interrupting / Cancelling Vocalizations
Mike: last week we discussed that any vocalization has the ability to interrupt or cancel a previous vocalization
Mike: we discussed this term / concept of a "cancellation token", assuming that that was one likely way the Speech API might work. but in fact, i've learned still more about the Microsoft Speech API and i no longer think that's an accurate way to describe the relationship
Mike: the way it actually works is that a voice communicates to the OS in the form of a blocking function for the duration of the actual vocalization. so the OS is aware of the vocalization and also able to cut of your vocalization to send you something new
Mike: the voice can detect when cancellation can occur, but it is never told explicitly that something *will* be cancelled.
Mike: this makes sense from software design sensibility, but for us it makes things a little harder. what this means is that we're able to observe when operation does occur, but we can't verify it as an endemic property of any given vocalization. the reality i think is that we will be dealing with a race condition
Mike: the way we deal with that is a sliding scale between something that is vulnerable to that race condition vs something that takes a very long time to test
michael fairchild: my gut says tracking interrupts is low priorty for most tests, except for ARIA Live, but i'm not even sure if that's in scope for the rest of the year
zcorpan: we can also calibrate out decision here based on our goals for overall speed of the test suite
BTT WG Agenda Item
s3ththompson: are we ready to share at BTT WG meeting 11/8?
michael fairchild: probably not, would like to get more ARIA-AT CG feedback first
s3ththompson: let's shoot for 12/8 meeting then, perhaps with earlier async feedback over email