Meeting minutes
Status of AT Automation API spec writing
4 open pull requests, representing the first 4 milestones
https://
Keypresses, Captured Output, and Initial Draft:
Preview: https://
PR: https://
James Scholes: joeb has left his review on the PR that builds upon the others
zcorpan_: just looking now... looks like the PR is still in draft. perhaps that's why he couldn't approve it
James Scholes: i'm not sure joeb's latest status, but we can move discussion back to github
zcorpan_: I wanted to ask about JSON Schema. Are you using that right now in the implementation?
James Scholes: we're not using JSON Schema at the moment, so i think we could potentially defer that
Next milestones
s3ththompson: the next milestones are currently: Active Commands, Headless Mode, and Internal State
s3ththompson: there was a discussion about moving Internal State to the next milestones. Any qualms with reordering?
zcorpan_: that works for me
James Scholes: Matt, did you have an idea about specific use cases for Internal State
Matt: we have a lot of tests which require specific mode testing... we can technically accomplish that by sending the correct key combinations... but it would be nice to be able to verify that we are in-fact in the right mode
James Scholes: should we also consider an API method to allow setting modes directly via the API?
zcorpan_: can you explain why keypresses is not sufficient for setting mode?
Matt: it requires more business logic... "do these keys until you get the right mode output from the screen reader"... it also depends on how you architect things. if the test is waiting for output before going to the next step in the test, then you have to build that async wait into your test. you have to tie the output and the command sequence together... that's a little tricky"
James Scholes: it also potentially makes tests more brittle if we're relying on very specific output and input patterns to get into the right mode
James Scholes: would setting and getting mode both be in this milestone?
zcorpan_: yes, i think so
s3ththompson: how does this work with VoiceOver, which is a "modeless" screen reader?
Matt: there are still things where VoiceOver has state, like Quick Nav
Matt: it really is a semantic distinction... i would say that Quick Nav is still a "mode" since it changes what keyboard shortcuts do, but on the other hand, it is totally optional
James Scholes: if i understand it, NVDA has a simple conception of modes, same with Narrator, but in JAWS, there is more overlap between forms mode and virtual cursor mode?
Matt: that is correct, JAWS also has Menu mode, application mode, forms mode, ...
Matt: so we have a definition of "mode" for ARIA-AT that is based on the superset of these different screen readers... or a simplification of how users actually deal with a problem. so it's intentionally an abstraction
s3ththompson: that makes sense, but raises 2 questions: 1) should we change terminology to make that abstraction clearer? and 2) no matter the name, are we clear that we're asking screen reader vendors to sign off on these abstractions by implementing api methods that are built around them?
Matt: yes, i think we are asking vendors to buy into this abstraction. "reading mode" and "interaction mode" are an attempt to be vendor neutral (and are derived from similar terminology in the ARIA spec)
James Scholes: my concern is that if this api is going to be built around these modes, we need to be very explicit about what these modes mean and there needs to be a concrete definition around that
Matt: In the context of VoiceOver in ARIA-AT, note that there's no modes, and there's a pre-requisite that all features are off
Matt: to come back to what we need though, we really are just trying to make these vendor-specific tests less flakey
zcorpan_: in that case, maybe we go back to the vendor-specific commands
James Scholes: what would that look like?
zcorpan_: it could just be `vo:setQuickNav` for example... no other AT would respond to that command, but you could write a library to abstract over these differences (or later build in an abstracted command)
James Scholes: if we're saying that the internal state that we're exposing is vendor-specific, how much should the spec say about what state should be exposed?
s3ththompson: i think it should be a goal to keep the spec as explicit and low-level as possible at first, so that userland libraries can start to build an intuition about the right abstractions... then down the road we can build those abstractions into the api... but we leave the door open for that process to take time, etc.
zcorpan_: to answer your question James: my initial response would probably to be as explicit as possible, e.g. "we expect these things for each vendor"
Matt: would we have something like core aam where there's a separate document for each vendor?
zcorpan_: maybe but it seems impractical to split up our spec document at this stage
James Scholes: i like the idea of a central neutral document with vendor-specific appendices