# Pastebin ziHYv45F
Cameron Cundiff to Everyone (20:31)
fwiwCircleCI and GitHub CI have SIP disabled, so you can launch VoiceOver in a CI environment programmatically today
I agree with James, to the point above, CI providers might not understand the implications of supporting VoiceOver and other AT automation on their cloud machines
James Craig (Apple) to Everyone (20:37)
SIP = System Integrity Protection
Not recommended to turn it off in production.
Cameron Cundiff to Everyone (20:38)
https://github.com/actions/virtual-environments/issues/4770
Weston Thayer to Everyone (20:38)
For CI, usually those are throw-away VMs running in a sandbox, which I would think greatly reduces the attack surface
Cameron Cundiff to Everyone (20:39)
Weston you’re right… the providers presumably guard against abuse
I just think the might need to be educated
Cameron Cundiff to Everyone (20:40)
Im frankly thrilled that it works, but would hate for the whole thing to be shutdown because of bad actors
Weston Thayer to Everyone (20:40)
Agreed, good point!
Cameron Cundiff to Everyone (20:42)
It’d be really great to have a DSL to abstract these interactions, e.g. “navigate to”
Similar to web driver abstractions: visit(url), fill_in(“#my-input”, with: “some text”)
Cameron Cundiff to Everyone (20:44)
The DSL would support multiple adapters… screen reader, switch access, mouse…
James Craig (Apple) to Everyone (20:47)
In the context of Abstraction, would it make more sense to abstract the lowest common denominator of shared commands (“e.g. next heading”) instead of keyboard shortcut (VO+Cmd+H, depending on settings)
Cameron Cundiff to Everyone (20:47)
Yes, 100%. Express the behavior, not the interaction
https://github.com/AccessLint/voiceover.js/blob/main/src/Commands.ts
I’d think something like navigate_to(“Some Heading”, via: “heading_outline”)
James Craig (Apple) to Everyone (20:50)
Mac has a very robust Accessibility Keyboard too. It’s also pretty locked down from a Sec perspective.
James Craig (Apple) to Everyone (20:50)
“Keyboard Viewer” in Accessibility System Prefs
/me points out that Z has been waiting patiently on the queue for a long time…
Z Goddard to Everyone (20:52)
Thank you James
Cameron Cundiff to Everyone (20:55)
Disagree... existing test approaches (usually) don’t say “move mouse to 100,100 and execute click” they say “click(id
Using key events as an API is kinda like sending mouse coords
Aaron I say that with respect :slightly_smiling_face:
Aaron Leventhal to Everyone (20:57)
@Cameron, I understand. I think mouse coords are a lot worse, since where things are laid out could change a lot based on screen size etc.
Aaron Leventhal to Everyone (20:57)
And, it would be very helpful if writing tests is something that doesn't require a lot of expertise
James Craig (Apple) to Everyone (20:57)
For the notes, how much info you need/want via speech synthesis? Not all speech engines allow the same thing (e.g. exact timings for substring synthesis, for example)
Monthly or less frequent preferred
Aaron Leventhal to Everyone (20:58)
E.g. if I could have my manual testers navigate a simple page, recording what they did, and the output is recorded as well
Cameron Cundiff to Everyone (20:59)
Yea for sure… but also having a more expressive approach that is idiomatic would make it easier to write white box tests
Aaron Leventhal to Everyone (20:59)
Maybe it's not either or, Cameron
Cameron Cundiff to Everyone (20:59)
Sure :slightly_smiling_face:
Aaron Leventhal to Everyone (21:00)
Another thing about an API, is some ATs have capabilities that others don't, and the capabilities change over time
Cameron Cundiff to Everyone (21:00)
I would love a pattern that supports swapping in a AT driver in existing playwright tests, for example
James Craig (Apple) to Everyone (21:00)
I have to drop…. Thanks for organizing.
Aaron Leventhal to Everyone (21:00)
So the API will need to evolve all the time or become quickly outdated
Cameron Cundiff to Everyone (21:00)
/nods @Aaron
Aaron Leventhal to Everyone (21:00)
whereas keystrokes would always "just work"