12:56:29 RRSAgent has joined #matf 12:56:33 logging to https://www.w3.org/2025/10/15-matf-irc 12:56:33 RRSAgent, make logs Public 12:56:34 please title this meeting ("meeting: ..."), JJ 12:56:38 Zakim, this is MATF 15 October 2025 12:56:38 got it, JJ 12:56:44 Meeting: MATF 15 October 2025 12:56:48 chair+ 12:56:57 agenda+ Second Draft backlog 12:57:01 agenda+ 1.4.1 Use of Color 12:57:10 agenda+ 1.4.2 Audio Control 12:57:14 agenda+ Virtual keyboard definition 12:57:16 present+ 12:57:19 agenda+ 2.5.8 Touch Target Size 13:01:22 Tim has joined #matf 13:01:31 pauljadam has joined #matf 13:03:55 present+ 13:04:48 zakim nominate a scribe 13:05:02 zakim propose a scribe 13:05:04 propose a scribe 13:05:22 nominate a scribe 13:05:47 zakim, nominate a scribe 13:05:47 Not knowing who is chairing or who scribed recently, I propose pauljadam 13:06:43 zakim, move to next agendum 13:06:43 agendum 1 -- Second Draft backlog -- taken up [from JJ] 13:06:43 GleidsonRamos has joined #matf 13:06:51 https://github.com/orgs/w3c/projects/147/views/1 13:08:16 JJ: has now been able to assign folks to issues on GitHub 13:08:43 zakim, move to next agendum 13:08:43 agendum 2 -- 1.4.1 Use of Color -- taken up [from JJ] 13:08:52 https://github.com/w3c/matf/issues/262#issuecomment-3334714461 13:09:51 JJ: discussing comment on Note 1 of Use of Color SC 13:10:59 JJ: in understanding document there is an exception for only color if there is difference in hue then it's not considered only color 13:11:17 If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater. For example, a light green and a dark red 13:11:18 differ both by color (hue) and by lightness, so they would pass if the contrast ratio is at least 3:1. Similarly, if content is distinguished by inverting an element's foreground and background colors, this would pass (again, assuming that the foreground and background colors have a sufficient contrast). 13:11:20 https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html 13:11:39 Yup, that even says invert. I have no concerns now. 13:12:18 JJ: reading the note about hue and lightness 13:13:50 Tim has joined #matf 13:13:56 Poll: close the issue for 1.4.1 note? 13:14:17 +1 13:14:25 +1 13:14:26 JJ: add +1 or -1 for the poll 13:14:44 +1 13:15:28 JJ: discussing that the issue needs to be linked to parent 13:15:31 Poll results: 3x +1 13:15:33 present+ 13:15:49 JJ: enough today about 1.4.1 13:16:22 zakim, move to next agendum 13:16:22 agendum 3 -- 1.4.2 Audio Control -- taken up [from JJ] 13:16:23 JJ: 1.4.2 audio control next on agenda 13:16:28 https://github.com/w3c/matf/issues/113#issuecomment-3334625627 13:17:11 JJ: discussing comment from mitchellevan about overall system volume 13:17:51 JJ: discussing comment android behavior where system volume control is different than talkback volume 13:18:33 JJ: discussing comment about different methods of changing system volume in android 13:18:40 Dav has joined #matf 13:19:18 JJ: discussing comment about should android need their own pause, stop or volume controls inside an android app since that's already built into the android system 13:19:40 JJ: this SC may be automatically passed due to android system behavior of controlling volume 13:20:13 JJ: discussing comment that mechanism must be widely available 13:20:39 1.4.2: If any audio on a web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. 13:20:46 q+ 13:20:54 Jamie has joined #matf 13:21:05 present+ 13:21:21 q+ 13:21:27 ack shoobe 13:22:01 schoobe01: how do we write this up about the audio control capabilities of android without talking about specific mobile OS 13:22:23 JJ: W3C does not want us to be that specific in our guidance 13:22:58 JJ: maybe have a note that shows an example of how to meet audio control 13:22:58 q+ 13:23:18 ack pauljadam 13:24:41 pauljadam: talking about how this is not about screen reader volume it's about app volume and system volume 13:25:32 Goal 13:25:33 A page that plays music or sounds doesn't disrupt people. 13:25:33 What to do 13:25:33 If you play audio content automatically, let people turn it down or off. 13:25:34 Why it's important 13:25:34 Sound distracts some people, and also interferes with screen readers. 13:26:07 ack Jamie 13:26:29 JJ: mentioned that goal is for users to turn off background sound and reduce volume to zero 13:27:11 Jamie: maybe we should hold off on trying to identify android and iOS specifics 13:28:16 Jamie: may not have much to change about this success criterion 13:28:58 q+ 13:29:07 ack pauljadam 13:30:31 JJ: if you press volume down and it affects only the running app then that could be a mechanism but if you change the volume for the whole OS and affects other apps then it would not be a mechanism 13:31:00 I agree with Paul 13:31:30 JJ: on iOS can't intercepts clicks on volume up or down button to adjust your app volume 13:31:54 JJ: if changing the volume affects other apps then it would not be a way to meet this SC 13:32:35 JJ: its reasonable to expect if people have auto playing audio they have a proper way to pause that 13:32:51 JJ: done for this sc for now 13:32:56 q? 13:33:09 JJ: asking what are the actions related? 13:33:45 Jamie: whats the issue that would keep us from moving forward on this? 13:34:22 Poll: Agree with response to 1.4.2: "If the audio control mechanism only affects the active app and not other apps, it is sufficient mechanism - if it also affects other apps, it does not pass 1.4.2" 13:34:36 JJ: added poll 13:34:53 +1 13:35:06 +1 13:35:15 -1 13:35:16 JJ: add +1 or -1 or 0 13:35:22 +1 13:35:33 +1 13:36:07 shoobe01: concern is that it does not say only that app 13:36:27 Replace "active app" with "overall system volume" / "app volume" 13:36:45 shoobe01: concern is not sure why system wide is bad 13:37:01 JJ: could say if audio does not affect overall system volume because that is aligned with the text 13:37:09 JJ: what do we consider over all system volume 13:37:29 JJ: if I change to another app and its also using the volume from the other app then its the system volume 13:38:05 JJ: should it say overall system volume, do we need to clarify that volume up down button would only affect that specific app to be a mechanism to pass 13:38:54 ACTION: Reply to https://github.com/w3c/matf/issues/113#issuecomment-3334625627 along the lines of "If the audio control mechanism only affects the active app and not other apps, it is sufficient mechanism - if it also affects other apps, it does not pass 1.4.2" but incorporating "overall system volume" 13:39:01 q+ 13:39:06 ack pauljadam 13:40:33 pauljadam: in app controls can simplify the way to adjust volume, especially for folks that might not be able to interact with the physical volume controls 13:41:34 JJ: discussing different ways AT users might adjust volume 13:41:57 JJ: sees benefit for in app controls vs using the physical volume buttons if AT user 13:42:07 zakim, move to next agendum 13:42:07 agendum 4 -- Virtual keyboard definition -- taken up [from JJ] 13:42:09 JJ: moving to next agenda 13:42:52 JJ: virtual keyboard definition does it need to be modified for use on mobile apps 13:43:49 JJ: reading shoobe01 comment about virtual keyboard on mobile, full keyboard access, external keyboard 13:44:10 Concern that this needs to be in scope because of the fundamentally different assumption of "keyboard" in mobile OSs. Today, most devices (in scope at least) use as their default the OSK (on-screen keyboard). This is virtual in the sense that it doesn't exist except on screen, but it is not virtual per my read of the WCAG/ICT def because it is the 13:44:10 primary input method. 13:44:10 Commands like iOS/iPadOS FullKeyboardAccess implies that the OSK (and on-screen tap, gesture?) is the /default/ device providing input (has the lower interrupt level or equivalent) and an external hardware KB plugged in is a proxy for that, could meet the current ICT def be a "virtual" keyboard. (!) 13:44:10 Anyone more of a low level developer who understands this or can look into it more than I can... or is this apparent — behavior to the end user — use by the mobile OSs enough justification to continue? 13:45:17 JJ: virtual keyboard has to be software not hardware 13:45:55 JJ: reading note Eye-gaze, morse code, speech, and switches (e.g. sip-and-puff) have all been used by virtual keyboards as input that generates "keystroke" output. 13:46:12 JJ: is on screen keyboard virtual keyboard or not 13:46:38 JJ: any more comments on this topic? 13:46:46 JJ: do we consider on screen keyboard to be virtual 13:46:49 I do 13:47:01 +1 13:47:07 +1 13:47:49 q+ 13:47:55 q+ 13:48:09 it sounds like this definition is talking more about the virtual keyboards that appear on desktop OS for AT users who have trouble physically using a real keyboard 13:48:23 ack Jamie 13:48:32 so I'm not sure that iOS keyboard actually generates keystrokes from a keyboard 13:49:09 Jamie: we're looking into definition written from WCAG2ICT and not WCAG 13:49:34 Jamie: is taking out the software piece tripping up folks 13:49:51 JJ: checking where virtual keyboard is being used 13:50:06 note 5 of https://w3c.github.io/wcag2ict/#applying-sc-2-1-1-keyboard-to-non-web-software 13:50:28 should we take out the "software" part at the beginning 13:50:38 and note 2 of https://w3c.github.io/wcag2ict/#applying-keyboard-interface-to-non-web-documents-and-software 13:51:13 virtual keyboard likely more a concern for WCAG2ICT like for kiosks but less an issue on mobile apps maybe 13:51:20 ack shoobe 13:52:03 shoobe01: concern about keyboard, alternative keyboard, and virtual keyboard definitions 13:52:50 ACTION: Double check the two notes where 'virtual keyboard' is used to determine whether we can use it as is or need to make modifications 13:52:56 q? 13:53:18 zakim, move to next agendum 13:53:18 agendum 5 -- 2.5.8 Touch Target Size -- taken up [from JJ] 13:53:33 https://github.com/w3c/matf/issues/155#issuecomment-3386057790 13:53:43 I will /have/ to leave 1-2 min before the hour, sorry I may miss some of this conversation then 13:53:51 JJ: reading comments on touch target size 13:53:53 Q+ 13:55:00 JJ: showing the graphics that have different touch target sizes in the comments 13:55:29 ack shoobe 13:55:35 https://github.com/w3c/matf/issues/10 13:55:36 JJ: maybe add some suggestions about not placing targets close to edge 13:55:49 https://github.com/w3c/matf/issues/10#issuecomment-3382847089 13:56:15 ACTION: Provide feedback on 2.5.5/2.5.8 research -> https://github.com/w3c/matf/issues/10 13:56:30 shoobe01: discussing proposal to reword, in the comments 13:56:50 JJ: read through comments and share thoughts please in the issue 10 13:57:47 JJ: touch target size is an important SC, may want to encourage developers to go beyond the minimum and should have some evidence to support 13:58:14 JJ: that's it for this week, next week may get through 3 issues, please comment on GitHub on open issues that are part of second draft scope 13:58:41 ACTION: Reply to https://github.com/w3c/matf/pull/274 if you agree (thumbs up) or disagree (thumbs down) 13:59:08 JJ: nice to see progress we still have a lot we are closing some issues, making progress 13:59:52 Zakim, list participants 13:59:52 As of this point the attendees have been shoobe, pauljadam, GleidsonRamos, Jamie 14:00:03 present+ Dav 14:00:20 present+ Tim 14:00:36 rrsagent, make minutes 14:00:37 I have made the request to generate https://www.w3.org/2025/10/15-matf-minutes.html JJ 14:00:44 regrets+ quintinb 14:00:56 regrets+ JulianK 14:01:03 rrsagent, make minutes 14:01:05 I have made the request to generate https://www.w3.org/2025/10/15-matf-minutes.html JJ 14:01:24 rrsagent, bye 14:01:24 I see 4 open action items saved in https://www.w3.org/2025/10/15-matf-actions.rdf : 14:01:24 ACTION: Reply to https://github.com/w3c/matf/issues/113#issuecomment-3334625627 along the lines of "If the audio control mechanism only affects the active app and not other apps, it is sufficient mechanism - if it also affects other apps, it does not pass 1.4.2" but incorporating "overall system volume" [1] 14:01:24 recorded in https://www.w3.org/2025/10/15-matf-irc#T13-38-54 14:01:24 ACTION: Double check the two notes where 'virtual keyboard' is used to determine whether we can use it as is or need to make modifications [2] 14:01:24 recorded in https://www.w3.org/2025/10/15-matf-irc#T13-52-50 14:01:24 ACTION: Provide feedback on 2.5.5/2.5.8 research -> https://github.com/w3c/matf/issues/10 [3] 14:01:24 recorded in https://www.w3.org/2025/10/15-matf-irc#T13-56-15 14:01:24 ACTION: Reply to https://github.com/w3c/matf/pull/274 if you agree (thumbs up) or disagree (thumbs down) [4] 14:01:24 recorded in https://www.w3.org/2025/10/15-matf-irc#T13-58-41