Meeting minutes
Status of the NVDA Implementation of Automation API Standard
James Scholes: we have been developing a POC concept. we have a standalone executable which is the remote end (server) which separately connects to NVDA via an addon. ultimately we hope that code will be upstreamed to NVDA itself. that serves as the listening side on NVDA
James Scholes: the local user of the API will connect to the remote end and start a session and the server will attempt to spin up that version of the AT
Matt_King: what happens if NVDA is already running?
James Scholes: i'm not sure that's covered in the spec... we need to figure out what happens when an instance is already running
James Scholes: my view is that the version that is spun up by the server will not be installed on the machine, it will be a separate version. the risk that we may make changes to your settings etc. might be too great
mzgoddard: that is analogous to how browsers handle things
Matt_King: but then are we asking screen reader vendors to support running two versions at the same time?
James Scholes: i don't think so.. i think the capability is left up to the vendor. if they can't run two instances at one time, then there would be some sort of error message and it simply wouldn't be possible
Matt_King: shouldn't the spec express a requirement about what should happen if other screen readers or running?
*are
James Scholes: I don't necessarily think so... if i was using this Automation API, i would want to spin up clean instances in the cloud, etc.
s3ththompson: there are other places than the spec for this sort of validation behavior to live
James Scholes: right, we plan to provide utilities for downloading the ATs, etc. but i don't think they belong in the spec
mzgoddard: the spec should detail what happens when a session fails, but probably not all the reasons it should fail
James Scholes: we implemented a proof of concept where sending messages to the remote end controls the implementation. that was working
James Scholes: the next milestone is to implement milestones 0, 1 from the spec, and work on exposing settings. we're targeting end of september for that work
michael_fairchild: out of curiosity, what langauge are you working in?
James Scholes: go for the remote end (since it produces easily distributable standalone binaries) and python for the nvda addon
Matt_King: speaking of milestone 1, settings, did Simon get a chance to update the spec since our last conversation about getallsupported sessions?
s3ththompson: yes
Matt_King: what about listing all possible values for each setting?
s3ththompson: we don't have that right now
James Scholes: I think that would be documentation related. there's certainly no easy way to do that in NVDA...
James Scholes: we certainly could look at validation errors in NVDA
s3ththompson: anything you're blocked on, on the spec side?
James Scholes: nothing blocking on our end. things are ticking along nicely
Repository location / open sourcing implementations
Matt_King: I'd love to discuss open sourcing a repository for the NVDA implementation. I don't think the w3c org is necessarily the right place or the right license for it
Matt_King: I don't have any strong opinions here, just want to bring it up for discussion
*discussion of correct license, org, etc.*
Matt_King: i will follow up internally to get a perspective on this
James Scholes: for now, we plan to open source it after we implement the work above, targeting September. we want to pick a license that is compatible with NVDA, etc.
s3ththompson: i think if there's any recommendation here from the arrangement of other projects like webdriver, it would be to have the work be as close to NVDA and their org as possible...
Upcoming milestones
s3ththompson: we've drafted Milestone 0: Protocol, Milestone 1: Settings, Milestone 2: Capture output, Milestone 3: Keypresses, upcoming is Milestone 4: Activate commands, Milestone 5: Headless mode, and Milestone 6: Internal state
s3ththompson: simon will be back in middle of september to work on upcoming spec milestones
Matt_King: should we foreground milestone 6?
James Scholes: i think internal state may be more important than commands / headless mode... but i also think that we need a way to access mode that doesn't rely on internal state
James Scholes: I opened a related issue under aria-at about modes: https://
James Scholes: but yes, we should probably reorder internal state as milestone 4
Matt_King: the second question, related to schedule is about TPAC
s3ththompson: we've started discussions at bocoup. can share more next week
Matt_King: I'm going. james craig is going i think. it's possible that glen gordon might be there
James Scholes: I don't think we've considered anything yet
michael_fairchild: i wasn't considering it yet
Matt_King: i think we should consider facilitating a session related to this