13:53:40 <RRSAgent> RRSAgent has joined #matf
13:53:44 <RRSAgent> logging to https://www.w3.org/2025/02/26-matf-irc
13:53:44 <Zakim> RRSAgent, make logs Public
13:53:45 <Zakim> please title this meeting ("meeting: ..."), JJ
13:53:46 <JJ> Zakim, this is MATF 26 February 2025
13:53:47 <Zakim> got it, JJ
13:53:53 <JJ> Meeting: MATF 26 February 2025
13:53:58 <JJ> chair+
13:54:05 <JJ> agenda+ WCAG2Mobile Call For Consensus (CFC) in AG WG
13:54:09 <JJ> agenda+ 2.4.7 Focus Visible
13:54:14 <JJ> agenda+ 3.2.1 On Focus
13:54:27 <JJ> agenda+ 4.1.2 Name, Role, Value
13:55:24 <Joe_Humbert> present+
13:56:39 <JJ> regrets+ Karla
13:56:47 <JJ> regrets+ JonGibbins
13:56:55 <JJ> regrets+ AlainVagner
13:58:35 <Tanya> Tanya has joined #matf
13:59:57 <GleidsonRamos> GleidsonRamos has joined #matf
14:00:07 <GleidsonRamos> present+
14:00:55 <Illai> Illai has joined #matf
14:00:59 <pauljadam> pauljadam has joined #matf
14:01:00 <Tanya> present+
14:01:23 <Carol> Carol has joined #MATF
14:02:07 <quintinb> quintinb has joined #MATF
14:02:13 <Illai> present+
14:02:14 <quintinb> present+
14:02:56 <julianmka> julianmka has joined #MATF
14:02:56 <JJ> Zakim, move to the next agendum
14:02:56 <Zakim> I don't understand 'move to the next agendum', JJ
14:02:59 <quintinb> scribe: quintinb
14:03:01 <JJ> move to the next agendum
14:03:06 <julianmka> present+
14:03:12 <Carol> present +
14:03:14 <JJ> move to next agendum
14:03:14 <Zakim> agendum 1 -- WCAG2Mobile Call For Consensus (CFC) in AG WG -- taken up [from JJ]
14:04:22 <Tim> Tim has joined #matf
14:04:33 <Tim> present+
14:05:19 <pauljadam> present+
14:05:41 <quintinb> JJ waiting for an email
14:06:15 <quintinb> @JJ pre cfc started 25 summary, next week actual CFC - 1 week delay
14:06:30 <Detlev> Detlev has joined #matf
14:06:53 <Detlev> present+
14:07:08 <quintinb> JJ Focus visble - JJ confused about keyboard operable user interface. This seems to focus on keyboard as opposed to keyboard interface
14:07:48 <quintinb> This SC seems to be written for keyboard and not keyboard interface
14:08:03 <Joe_Humbert> q+
14:08:54 <quintinb> @JJ reading comments on GitHub
14:09:19 <pauljadam> Visible does not mean it has a certain contrast, that's not defined.
14:10:34 <quintinb> @JJ but customisable - then when developers have the capacity to change the focus indicator, it should be visible. But JJ means the system indicator
14:10:48 <quintinb> pauljadam iOS won't let you chnage the indicator
14:11:03 <quintinb> @JJ it's not possible to modify the system
14:11:30 <JJ> ack Joe_Humbert
14:11:37 <JJ> q?
14:12:06 <Jamie> Jamie has joined #matf
14:12:10 <Jamie> present+
14:12:21 <pauljadam> q+
14:12:25 <Jamie> qw
14:12:27 <Jamie> q+
14:12:34 <quintinb> Joe_Humbert - we have said this only applies to keyboard, but switch access also uses the keyboard interface. This might not be the same on iOS and Android
14:13:01 <quintinb> by the way, Switch Control / Access is using the KB interface
14:13:21 <quintinb> I've been doing this with Ally Keys
14:14:23 <quintinb> Joe_Humbert then why did FKA preceed them?
14:14:38 <quintinb> pauljadam probably due to numbers (sorry for paraphrasing)
14:15:22 <JJ> q?
14:15:29 <JJ> ack pauljadam
14:15:30 <quintinb> @JJ we need to be careful about wording
14:16:10 <JJ> ack Jamie
14:16:12 <quintinb> pauljadam on switch control - if it's keyboard accessible, switches work fine. I wouldn't change the definition. All you need to test is keyboard. @JJ confirms
14:16:20 <quintinb> Jamie have we confirmed that?
14:16:25 <Detlev> q+
14:17:12 <quintinb> Switches allow for actions, which Keyboard does not, but other than that I haven't noticed much
14:17:26 <quintinb> Focus and selection are the same
14:18:16 <Joe_Humbert> q+
14:18:36 <quintinb> pauljadam are we extending the scope of wcag if we explicitly require switch access?
14:18:40 <quintinb> Jamieyes
14:18:59 <quintinb> JJ mobile is changing a lot of the landscape
14:19:21 <quintinb> pauljadam WCAG doesn't say to test for focus color in switch control
14:19:57 <JJ> ack Detlev
14:19:57 <quintinb> @JJ I wonder how we should be reading this sc
14:20:19 <JJ> "Any" keyboard operable user interface has "a mode" of operation where the keyboard focus indicator is visible.
14:20:56 <quintinb> Detlev since switch is next / activate but keyboard allows for more granular control. Does that map equivalently?
14:22:12 <quintinb> @JJ are we just assuming switch access works - it's confused me in the past. 2.1.1 doesn't mean that switch and touch has to work the same. If the keyboard has equivalent control
14:23:07 <quintinb> pauljadam you could even use the enter key instead of a submit button
14:23:27 <JJ> ACTION: Research on Android + iOS the behavior of Switch Control and External Keyboard focus indicators
14:24:27 <quintinb> quintinb the Switch interface allows for "build your own keyboard" as well as auto select etc.
14:24:30 <Jamie> q+
14:24:40 <Joe_Humbert> 1+ to quintinb about switch access is very customizable
14:24:41 <pauljadam> That's why you keep it to Keyboard
14:24:55 <JJ> ack Joe_Humbert
14:25:06 <github-bot> github-bot has joined #matf
14:25:13 <JJ> ack Jamie
14:25:29 <pauljadam> If you add accessibility Actions on iOS it works for VoiceOver, Keyboard, Switch all the same
14:25:31 <quintinb> I learned what I know from pauljadam's stuff, lol
14:25:51 <pauljadam> :)
14:26:16 <pauljadam> keep as is will be my response mostly :)
14:26:26 <quintinb> +1 pauljadam
14:26:51 <quintinb> JJ we could add a note about best practice regarding accessibility interface
14:27:06 <pauljadam> we going to start talking about Eye Tracking too? probably too hard to discuss every possible AT on Mobile
14:27:21 <julianmka> q+
14:27:38 <JJ> Keep the text as is, but add note about best-practices for focus visible for assistive technologies?
14:27:40 <JJ> ack julianmka
14:27:53 <pauljadam> So regular WCAG does not say "Make sure you do switch controls too" But Mobile WCAG needs to say that?
14:28:39 <quintinb> julianmka we should keep to a similar approach that we've been taking regarding mobile being different. We should be aware of what the system supports and keep with intent rather than being explicit on every possible AT
14:29:20 <quintinb> julianmka windows doesn't support switch control
14:30:05 <Joe_Humbert> q+
14:30:05 <JJ> Poll: Keep text as is, add note about supporting focus indicators for other types of assistive technologies?
14:30:24 <Tim> +1
14:30:25 <GleidsonRamos> +1
14:30:26 <pauljadam> Keep as is, no note needed
14:30:28 <Jamie> +1 plus note
14:30:29 <Tanya> +1
14:30:31 <Detlev> +1
14:30:36 <quintinb> +1
14:30:40 <Illai> +1
14:30:41 <julianmka> +1
14:30:56 <Carol> +1
14:31:01 <pauljadam> What if Apple or Android changes later?
14:31:10 <pauljadam> Are we going to define everything possible for a developer?
14:31:33 <JJ> ack Joe_Humbert
14:32:03 <quintinb> Joe_Humbert do we need to acknowledge that devs can change the original focus indication
14:32:36 <quintinb> JJ we could use a similar note to 1.1.1 where not every platform does something
14:33:18 <pauljadam> I'm not sure it's worth the effort of if we'd have full accuracy if we start defining what is possible and what is not possible for each platform.
14:33:31 <JJ> ACTION: Add second note: Not all mobile platforms provide a way to programmatically change the keyboard focus indicator.
14:34:17 <JJ> move to next agendum
14:34:17 <Zakim> agendum 2 -- 2.4.7 Focus Visible -- taken up [from JJ]
14:34:43 <quintinb> (actually 3.2.1)
14:35:41 <quintinb> JJ what do we see as a component, and what do we consider as a change of context
14:35:52 <quintinb> JJ is element different from component?
14:35:55 <pauljadam> UI component, UI control, UI element all the same thing
14:36:03 <quintinb> +1 pauljadam
14:36:36 <pauljadam> if you want to update Change of Context definition then just remove the word "Web" from "Web page"
14:36:45 <JJ> move to next agendum
14:36:45 <Zakim> agendum 3 -- 3.2.1 On Focus -- taken up [from JJ]
14:38:16 <quintinb> @JJ do we need to redfine / modify the definition of UIC (User Interface Component)
14:39:07 <pauljadam> definitions of UI components seems fine and does not need a change since it's written generically and does not say "Web" specifically
14:39:15 <Joe_Humbert> q+
14:39:21 <quintinb> JJ sometimes a component can be a combination of controls
14:39:59 <JJ> ack Joe_Humbert
14:40:30 <quintinb> Joe_Humbert re:definitions, would those be impacted by the views discussion last week. Like more for subview and component
14:41:22 <quintinb> @JJ I am confused about what is being perceived by users - is it what you can control
14:41:43 <quintinb> JJ if it can receive focus it's generally interact-able
14:42:44 <quintinb> What concerns me: "page" and "viewport"
14:42:57 <JJ> q?
14:43:33 <JJ> quintinb: change of context, might need to replace "page" and "viewport"
14:43:44 <pauljadam> I would replace "Web page" with "page"
14:43:49 <pauljadam> clear
14:43:53 <quintinb> JJ is UIC clear?
14:44:00 <Carol> Yes
14:44:01 <quintinb> +1 (it is clear)
14:44:11 <GleidsonRamos> yes
14:44:17 <Jamie> q+
14:44:27 <JJ> ack Jamie
14:44:36 <Tim> +1
14:45:08 <quintinb> Jamie I think we documented in the ticket about UIC that we have open to make that consistent pattern when to use component and UIC. Or is it in the note 3? Is that a note from WCAG?
14:45:18 <quintinb> JJ yes it's a part of WCAG
14:45:30 <quintinb> Jamie because that tripped me up
14:46:09 <quintinb> Jamie there is some wording here that may not only apply to this SC only
14:46:42 <JJ> q?
14:46:47 <quintinb> JJ it seems that UIC refers to interactive features
14:47:39 <quintinb> JJ for example 3.2.4 just says "component" - as opposed to UIC
14:48:01 <quintinb> Joe_Humbert I think that's addressed in Note 3 under UIC
14:49:18 <quintinb> pauljadam an element could be an image. Page element vs UIC does have some confusion associated
14:49:28 <pauljadam> component and control seems more specific than element which could be more generic
14:49:30 <quintinb> Joe_Humbert is component defined?
14:49:33 <quintinb> JJ no
14:50:01 <GleidsonRamos> q+
14:50:18 <GleidsonRamos> q-
14:50:26 <JJ> ACTION: Create issue in WCAG for user interface component (control) vs component (element?)
14:50:56 <pauljadam> If you say "Design System Elements" that could mean ever possible element that is not operable as well, "Design System Components" or "Controls" means only the operable UI controls the user would be tapping and clicking on
14:51:03 <JJ> move to next agendum
14:51:03 <Zakim> agendum 4 -- 4.1.2 Name, Role, Value -- taken up [from JJ]
14:51:11 <quintinb> Oh so a small one
14:52:26 <Illai> q+
14:52:40 <quintinb> q+
14:53:22 <pauljadam> Yeah it think everyone fails something if it has the wrong role or the wrong state.
14:53:39 <pauljadam> You can't put aria-expanded=false if it's visually expanded.
14:54:40 <JJ> ack Illai
14:55:51 <pauljadam> I'd remove "Web" and "HTML" from that definition
14:56:05 <quintinb> Illai: 1. Regarding role - it is being implicitly referred to in 1.3.1. But there is some confusion in mobile in 4.1.2 in the note. If you are using native elements you should be "good" - we don't have a real definition of what a native element means
14:56:06 <Detlev> q+
14:56:08 <pauljadam> same deal for native apps
14:57:26 <quintinb> JJ there has been a change in WCAG addressing the web part about something custom or not. XML vs Compose: is that native?
14:57:28 <JJ> close the queue
14:57:28 <pauljadam> if it's not in a web view then it's native
14:57:31 <JJ> Zakim, close the queue
14:57:31 <Zakim> ok, JJ, the speaker queue is closed
14:57:41 <JJ> ack quintinb
14:58:03 <JJ> pauljadam - yes it is "native", but is it provided by the OS or custom built by a developer
14:58:22 <JJ> it relates to the "unmodified" exception
14:58:39 <GleidsonRamos> q+
14:59:08 <JJ> ack Detlev
14:59:11 <quintinb> quintinb role can be strictly defined, but it has changed even in Android views to compose. It's a careful definition
14:59:21 <JJ> GleidsonRamos - please comment in the chat or on Github
14:59:26 <GleidsonRamos> ok
14:59:28 <GleidsonRamos> q-
15:00:09 <quintinb> Detlev from a practical perspective there are elements that are compound, some elements have actions. There are many different types of roles (e.g. action descriptions) - is that a fail?
15:00:39 <pauljadam> on iOS if you combine the focus of a card and give it accessibility actions then the button role is still spoken if there is a button inside the card
15:01:04 <Joe_Humbert> For previous agenda item 3.2.1 https://github.com/w3c/wcag/issues/4252
15:01:13 <Detlev> pauljadam intersting...
15:01:36 <pauljadam> I have a Cards demo in my a11y techniques iOS app
15:05:39 <JJ> Zakim, list participants
15:05:39 <Zakim> As of this point the attendees have been Joe_Humbert, GleidsonRamos, Tanya, Illai, quintinb, julianmka, Tim, pauljadam, Detlev, Jamie
15:05:45 <JJ> rrsagent, make minutes
15:05:46 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/26-matf-minutes.html JJ
15:08:14 <JJ> rrsagent, bye
15:08:14 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2025/02/26-matf-actions.rdf :
15:08:14 <RRSAgent> ACTION: Research on Android + iOS the behavior of Switch Control and External Keyboard focus indicators [1]
15:08:14 <RRSAgent>   recorded in https://www.w3.org/2025/02/26-matf-irc#T14-23-27
15:08:14 <RRSAgent> ACTION: Add second note: Not all mobile platforms provide a way to programmatically change the keyboard focus indicator. [2]
15:08:14 <RRSAgent>   recorded in https://www.w3.org/2025/02/26-matf-irc#T14-33-31
15:08:14 <RRSAgent> ACTION: Create issue in WCAG for user interface component (control) vs component (element?) [3]
15:08:14 <RRSAgent>   recorded in https://www.w3.org/2025/02/26-matf-irc#T14-50-26