Meeting minutes
AT Automation Update
ST: We've been working on potential approaches for making the "automation voice" accessible
ST: wrote a description of the issue here: https://
MP: we're still thinking about automation as a system of tools that work together. at a high level, they might be coordinated by a consistent API, but at a low-level they might be implemented in different ways across different OS/AT combos
MP: 1. Screen reader + screen reader, 2. Screen reader + screen reader in VM, 3. Screen reader + plugin to retrieve speech data, 4. Automation voice + automated toggling, 5. Automation voice + ability to vocalize, 6. Automation voice + forward to built-in voice, 7. AssitivLabs
MF: For 7. AssistivLabs, would that use automation voice or a plugin?
MP: could use either
MF: so just to step back and restate the question... this is a question of both the UX and usability...
MP: yes, but i want to leave space to recognize that this may be dangerous, not just a UX issue
MF: how do non-sighted at voice developers build at voices? i think that's the crucial question. i don't feel comfortable making that determination
ST: perhaps we could reach out to some developers in our extended network to try to collect some feedback there
MP: if we did have to write a vocalizer, the question becomes: would we have to support languages other than english? how much does this explode the complexity of what we're working on
MP: also, to speak to the plausibility of wrapping the automation voice in a VM... it seems quite a challenge to work out the platform/licensing issues around spinning up VMs on all OSes... seems also like a lot of extra work
MF: I think the next step is to reach out to James and other non-sighted contributors. My take would be to go for 4. Automation voice + automated toggling, given the complexities around the other options, but I would defer to community consensus here
MP: By the way, speaking of feasibility on macOS, we investigated https://
MP: since it's not event-based, it can't tell us if the same thing was uttered twice, or if two things were uttered in rapid succession.
MF: i can definitely see that being problematic, especially for something like aria live regions
<westont> re: custom voices on macOS, https://
<westont> > CereProc's SAPI voices are compatible with Microsoft SAPI 5 and are supported on Windows XP, Windows Vista, Windows 7, Windows 8, Windows 8.1 and Windows 10. They appear in the Windows Text-to-Speech Control Panel. We recommend using our SAPI voices on systems with at least a 1GHz processor and 256MB RAM. CereProc's Mac voices are supported on Lion, Mountain Lion, Mavericks, Yosemite, El Capitan, Sierra, High Sierra, Mojave and Catalina. The[CUT]
<westont> ... They add to the system voices list, found under 'Accessibility > Speech' in 'System Preferences'.
ST: want to also bring up that we should still pursue as a long-term project getting first-party support for some new shared APIs
<westont> Here's the NVDA lib by Sebastian (using NVDA's log) https://
WT: just want to underscore that in the long run we really do need this kind of API. I spoke with someone from Material Design who worked on a similar black box library (https://
<westont> And here's an example test using that lib: https://
MP: i want to caution against saying that a first-party API would obviate the need for the black box testing approach... there's a question of trust... we might always want to validate that the block box testing yields the correct assertions
ST: good point, i guess it's not so much a short term and long term option, so much as a 2-pronged approach
MP: right, and i would also say that it is to our benefit to highlight other use cases outside of strict assertion testing when we go to vendors to ask for better API support
<westont> Another potential macOS 3rd party voice example: https://
MF: Next steps: run proposal by james, seth to try to contact external at voice contributors