Meeting minutes
Mike Pennisi (Bocoup)
Renaming repositories: aria-at-automation and aria-at-automation-driver
MP: Foirst is the automation repo
This has the proposal text for the standard
How do we use name to generalize and make it less about ARIA.
Thinking of renaming this repo to "AT Driver"
Do folks feel like this is acceptable?
This would change the name of the spec proposal as well.
MK: In terms of communications and public perception into the future, we want a short and meaningful like "AT Driver". That's what I feel we're aiming for.
mk: I'd like to say that for the long term we need a short descriptive name
MF: Concerned about not having concrete plans for driving AT other than just screen readers
MK: We have intentions but the plans are not concrete yet due to funding. However, the spec is designed to support AT other than just screen readers.
JS: There are parts of the spec that are already quite generic, e.g., settings.
JS: Other parts are very specific to screen readers, e.g., capturing speech output.
We also don't have anything specific to braille, which might make it even more sr specific.
We could find out later that the spec is difficult to apply broadly beyond screen readers.
Part of this is that we have a lot of unknowns.
MF: Knowing we have those unknowns is what gives me pause
MP: Perhaps we should have some concrete research along these lines to ensure feasibility for other AT is practical.
MK: Adding chapters and adding capabilities are natural parts of the W3C's specification process
MF: sometimes a monolithic spec can make the spec harder to maintain
sometimes a separate spec makes it more nimble.
Js: sometimes people apply WCAG to non-web contexts b/c there is no other option
MF: Boils down to there are a lot of unknowns, but OK with changing to AT driver even with those unknowns.
RESOLUTION: The CG will move forward with renaming the aria-at automation repository to AT Driver
mp: Next is the aria-at automation driver repo
This contains the code that runs tests in a way that is screen reader agnostic.
This code hooks into the speech synthesis output.
It hooks into platform-specific APIs to simulate key presses.
By calling it aria-at automation, it doesn't support other use cases.
Previously discussed calling it "Generic AT Driver", but this a bit to generic of a name.
We might want to think about how to clarify its relationship with specific screen readers.
This approach is fundamentally limiting in terms what it can achieve. Because it is agnostic of the screen reader, the parts that deal with internals, like getting settings, there is not an anologous solution in the generid driver. That probably will not evern be in scope for this driver; it won't be feature complete.
JS: What are the aims and non-aims of the generic driver?
js: Do we want to support any screen reader, even if that screen reader does not exist?
that is, do wewant it to be fully generic?
Not sure what the utility of that is.
Each screen reader would need to be instructed to use it, that is JAWS, does not use SAPI by default.
So, it is not already generic b/c you have to write custom code to use it.
MK: I think that we probably want to have a propensity towards narrowing the scope of this driver and its implementation to whatever we truly need for the project to be successful. We should not invest time or money in going beyond the uses cases that are vital to the success of the project
JS: Generic Driver sounds like the wrong names as its not that generic, it won't work out of the box
MK: A driver is an ambitious name. AT driver is intentionally ambitious
MK: We have long term goals for the project. This repo is more tactical, and is a way to test the implementation with a specific AT
MK: For now we can use it, as we don't have an implementation of the driver
MK: At some point in the future, if we were to use this driver at all, it would be to validate the JAWS version of the Driver
MP: I was not thinking of it in the same way, I am open to what you are saying. What I'm really hearing, specifically about the naming, is the Audience. So for the naming, we don't necessarily intend to focus on people who plan to use this for their own projects. We would fix our own bugs, but not bugs other people report for their projects
MP: This is adjacent to the AT Driver proposal
MK: Do you think I am being to narrow in my thinking?
MP: No I don't, at least at this stage, when things are ramping up it helps us to be more conservative. Its easier to say in the future when we are more confident to open it up
MP: We could revise that decision in the future, rather than if we committed now it would be harder to reduce the scope
MK: For the SDK, I think what we really want to promote and include is the NVDA Addon that PAC has been working on. We wouldn't include anything in this repo
JS: I've been seeing the SDK in a similar way. It would be aimed at people implementing something using the spec
MK: as you said earlier, this implementation is limited, it wouldn't be prudent to include it in the SDK
MP: Its really making me wonder about the utility about packaging this as a single tool.
MP: If you were installing on mac or windows, it would pull in the packages you would need
MK: That also depends on our resources and how many people we have.
MK: If we had engineers from Google join the project it would change
MP: I want to make sure we have a little time for Z to speak about his new work.
MP: Can we get to a new name?
MK: Its currently called ARIA AT Automation Driver, maybe that is okay for now
MP: Okay the readme currently is like an old school web ring that connects all of these repos together
MP: Maybe we don't hide the repo, but we mention it in a less center focused way
MK: Yes when people come to the ARIA AT repo, we want them to focus on the NVDA add on and the SDK
MP: Okay great
MP: I will do that with a seperate PR. Matt there already is a PR for some readme changes
MP: Lola also now has higher credentials and could handle it
MP: Thank you all for that. We can now move onto the topic of Z's progres
Progress update on the automation driver (macOS support)
Z has been taking over from where I left off, how can we use the API from Apples latest release, to power the ARIA AT Automation driver
MP: Thats been an uphill battle, as the one piece of documentation apple released, did not provide a clear understanding of why it wasn't working
Z: We have been reviewing an api released in MAC 13 1os 16. It has a guide to build a tool. The example provides instruction to create a simple application
Z: I've built and run the example. The guide has you walk through a few steps, once you add the voice it recomends you go to the speech content performance setting and select the voice to test
z: we haven't been able to get the voice to appear there
z: I've been trying to figure out why the voice isn't appearing, I've been reviewing MAC Console interface, which gets a lot of information. I've filtered the logs to the name of the application
z: I get alot of logs for system software used in the background
z: the console log is indicating the that application is querying for user input, but that isn't related to our use case
z: It gets alot of existing system logs, for the extension launching or applications interacting with it, but I haven't been able to view the logs I added
z: APEX is abbreviated as APPX, which confuses search enginers
z: James previously mentioned E speak that implemented the spec
z: They do some different things there, but I haven't found anything yet that may help us get it working
z: The next thing to try is to build the espeak, I think I can build it for MAC, it builds for iOS
z: It truncates some features when you build for MAC
z: If can get the voice to appear for the speech content, that would be a step forward to use this API
MK: You opened a support ticket with apple right?
MP: thats right yes
MK: You said it got assigned but you don't have any feedback yet?
MP: Yes
MP: It has not been triaged. Apple support has some guarantees in how they will respond. They said they don't consider it closed, but I raised this issue one month ago
MK: Should we send this issue to James craig with the support ticket, to ask for him to help us out?
MP: Yes I would like to
MP: I'm reluctant to do that, I wouldn't do that lightly. I want Z to finish his research into e speak so we have a really good argument
MK: Okay we also want to be aware of not waiting to long. This is on our critical path for the project
MP: Even though its on the critical path, at this point in time it wont have a major impact, but later in the year once things are automated it would have a bigger impact
Z: Yeah its alot of grunt work to research
z: It could be some setting hidden in x code