20:09:15 <RRSAgent> RRSAgent has joined #aria-at
20:09:15 <RRSAgent> logging to https://www.w3.org/2022/12/05-aria-at-irc
20:09:25 <Matt_King> rrsagent, make log public
20:09:38 <Zakim> Zakim has joined #aria-at
20:09:54 <michael_fairchild> scribe+
20:09:55 <Matt_King> present+
20:10:00 <michael_fairchild> present+
20:10:02 <jugglinmike> present+
20:10:36 <michael_fairchild> TOPIC: progress update for the ARIA-AT Automation Driver
20:10:41 <Matt_King> MEETING: ARIA-AT Community Group Automation Workstream
20:12:07 <michael_fairchild> MP: Enrolled in the Apple Developer Program to get support with the Apple example that is not working for the new speech synth API.
20:13:53 <michael_fairchild> MK: I followed the example from Apple but it did not work
20:14:08 <michael_fairchild> (Sorry, that was MP)
20:14:38 <michael_fairchild> MK: We could potentially reach out directly to contacts at Apple if needed.
20:16:34 <michael_fairchild> TOPIC: Screen Reader modes
20:16:56 <jugglinmike> https://github.com/w3c/aria-at-automation/issues/15
20:18:04 <michael_fairchild> MP: We would like to better understand how to handle the concept of modes for screen readers that do not have modes
20:18:48 <michael_fairchild> JS: The word mode is a little overloaded, because some screen readers also have review modes (not related to focus and browse modes)
20:19:35 <michael_fairchild> MK: We don't need to use the word mode within the API itself
20:20:20 <michael_fairchild> MK: mode might also fit under settings/preferences
20:23:15 <michael_fairchild> JS: Voice Over might have the concept of modes with quick nav, but that is not in scope for ARIA-AT
20:27:32 <michael_fairchild> JS: I don't feel comfortable throwing away the idea of an internal state
20:30:52 <michael_fairchild> JS: Key take away: state is a conversation worth having, but it shouldn't revolve around an abstract idea of modes
20:31:13 <michael_fairchild> MK: Mode = a specific combination of settings/states
20:31:34 <michael_fairchild> MP: Are there cases where the mode might change depending on the content?
20:31:38 <michael_fairchild> MK: yes
20:32:18 <michael_fairchild> MP: That seems like the differentiating state. But settings are modified and expected to remain the same until you modify them again.
20:32:53 <michael_fairchild> MK: that's a valuable point, and that's probably why apple says VoiceOver is modeless.
20:35:18 <michael_fairchild> JS: Let's revisit the settings/state conversation on a latter date
20:35:28 <jugglinmike> https://github.com/w3c/aria-at-automation/issues/34
20:35:31 <michael_fairchild> TOPIC: abstracting screen reader specific modifier keys
20:39:25 <michael_fairchild> 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.
20:42:27 <michael_fairchild> MP: You are confirming my understanding. The word modifier is a bit overloaded here.
20:43:17 <michael_fairchild> (discussion of a modifier key being used to send a command by itself, control is an example used to stop screen reader output)
20:54:12 <michael_fairchild> MP: it sounds like we need to support key down and up functionality
20:54:17 <michael_fairchild> MK: Yes
20:56:38 <michael_fairchild> TOPIC: normative text for settings
20:56:54 <michael_fairchild> MP: should we tighten up the normative text?
20:57:19 <jugglinmike> https://github.com/w3c/aria-at-automation/issues/48
20:57:28 <jugglinmike> https://github.com/w3c/aria-at-automation/issues/49
21:00:41 <Matt_King> rrsagent, make minutes
21:00:41 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/05-aria-at-minutes.html Matt_King
21:04:40 <Matt_King> Matt_King has joined #aria-at