19:03:38 <RRSAgent> RRSAgent has joined #aria-at
19:03:38 <RRSAgent> logging to https://www.w3.org/2022/08/15-aria-at-irc
19:03:51 <s3ththompson> MEETING: ARIA-AT Automation and Community Group Meetings
19:04:07 <s3ththompson> rrsagent, make minutes
19:04:07 <RRSAgent> I have made the request to generate https://www.w3.org/2022/08/15-aria-at-minutes.html s3ththompson
19:04:11 <s3ththompson> SCRIBE: s3ththompson
19:04:14 <s3ththompson> present+
19:04:19 <s3ththompson> rrsagent, make logs public
19:04:36 <Sam_at_PAC> present+
19:04:41 <zcorpan_> present+
19:07:47 <s3ththompson> TOPIC: Status of AT Automation API spec writing
19:09:32 <s3ththompson> 4 open pull requests, representing the first 4 milestones
19:09:39 <s3ththompson> https://github.com/w3c/aria-at-automation/pulls
19:10:33 <s3ththompson> Keypresses, Captured Output, and Initial Draft:
19:10:38 <s3ththompson> Preview: https://pr-preview.s3.amazonaws.com/w3c/aria-at-automation/pull/26.html
19:11:02 <s3ththompson> PR: https://github.com/w3c/aria-at-automation/pull/26
19:11:21 <s3ththompson> James Scholes: joeb has left his review on the PR that builds upon the others
19:11:55 <s3ththompson> zcorpan_: just looking now... looks like the PR is still in draft. perhaps that's why he couldn't approve it
19:12:19 <s3ththompson> James Scholes: i'm not sure joeb's latest status, but we can move discussion back to github
19:18:05 <s3ththompson> zcorpan_: I wanted to ask about JSON Schema. Are you using that right now in the implementation?
19:18:17 <s3ththompson> James Scholes: we're not using JSON Schema at the moment, so i think we could potentially defer that
19:18:26 <s3ththompson> TOPIC: Next milestones
19:18:52 <s3ththompson> s3ththompson: the next milestones are currently: Active Commands, Headless Mode, and Internal State
19:19:08 <s3ththompson> s3ththompson: there was a discussion about moving Internal State to the next milestones. Any qualms with reordering?
19:19:18 <s3ththompson> zcorpan_: that works for me
19:19:33 <s3ththompson> James Scholes: Matt, did you have an idea about specific use cases for Internal State
19:20:18 <s3ththompson> 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
19:20:36 <s3ththompson> James Scholes: should we also consider an API method to allow setting modes directly via the API?
19:23:00 <s3ththompson> zcorpan_: can you explain why keypresses is not sufficient for setting mode?
19:24:01 <s3ththompson> 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"
19:27:22 <s3ththompson> 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
19:28:19 <s3ththompson> James Scholes: would setting and getting mode both be in this milestone?
19:28:23 <s3ththompson> zcorpan_: yes, i think so
19:30:04 <s3ththompson> s3ththompson: how does this work with VoiceOver, which is a "modeless" screen reader?
19:31:53 <s3ththompson> Matt: there are still things where VoiceOver has state, like Quick Nav
19:32:38 <s3ththompson> 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
19:33:13 <s3ththompson> 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?
19:34:29 <s3ththompson> Matt: that is correct, JAWS also has Menu mode, application mode, forms mode, ...
19:35:44 <s3ththompson> 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
19:37:32 <s3ththompson> 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?
19:38:17 <s3ththompson> 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)
19:42:14 <s3ththompson> 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
19:42:45 <s3ththompson> 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
19:49:37 <s3ththompson> Matt: to come back to what we need though, we really are just trying to make these vendor-specific tests less flakey
19:49:53 <s3ththompson> zcorpan_: in that case, maybe we go back to the vendor-specific commands
19:49:58 <s3ththompson> James Scholes: what would that look like?
19:50:30 <s3ththompson> 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)
19:51:20 <s3ththompson> 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?
19:56:26 <s3ththompson> 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.
19:57:01 <s3ththompson> 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"
19:57:15 <s3ththompson> Matt: would we have something like core aam where there's a separate document for each vendor?
19:59:24 <s3ththompson> zcorpan_: maybe but it seems impractical to split up our spec document at this stage
19:59:38 <s3ththompson> James Scholes: i like the idea of a central neutral document with vendor-specific appendices
20:00:07 <s3ththompson> rrsagent, make minutes
20:00:07 <RRSAgent> I have made the request to generate https://www.w3.org/2022/08/15-aria-at-minutes.html s3ththompson