– DRAFT –
ARIA-AT Community Group Automation Workstream

progress update for the ARIA-AT Automation Driver

MP: Enrolled in the Apple Developer Program to get support with the Apple example that is not working for the new speech synth API.

MK: I followed the example from Apple but it did not work

(Sorry, that was MP)

MK: We could potentially reach out directly to contacts at Apple if needed.

Screen Reader modes

<jugglinmike> https://github.com/w3c/aria-at-automation/issues/15

MP: We would like to better understand how to handle the concept of modes for screen readers that do not have modes

JS: The word mode is a little overloaded, because some screen readers also have review modes (not related to focus and browse modes)

MK: We don't need to use the word mode within the API itself

MK: mode might also fit under settings/preferences

JS: Voice Over might have the concept of modes with quick nav, but that is not in scope for ARIA-AT

JS: I don't feel comfortable throwing away the idea of an internal state

JS: Key take away: state is a conversation worth having, but it shouldn't revolve around an abstract idea of modes

MK: Mode = a specific combination of settings/states

MP: Are there cases where the mode might change depending on the content?

MK: yes

MP: That seems like the differentiating state. But settings are modified and expected to remain the same until you modify them again.

MK: that's a valuable point, and that's probably why apple says VoiceOver is modeless.

JS: Let's revisit the settings/state conversation on a latter date

<jugglinmike> https://github.com/w3c/aria-at-automation/issues/34

abstracting screen reader specific modifier keys

JS: If you are on MacOS the default modifier keys are also system modifier keys. But insert, and capslock are not system modifier keys. To users, they behave the same, but programmatically they might behave differently.

MP: You are confirming my understanding. The word modifier is a bit overloaded here.

(discussion of a modifier key being used to send a command by itself, control is an example used to stop screen reader output)

MP: it sounds like we need to support key down and up functionality

MK: Yes

normative text for settings

MP: should we tighten up the normative text?

<jugglinmike> https://github.com/w3c/aria-at-automation/issues/48

<jugglinmike> https://github.com/w3c/aria-at-automation/issues/49