– DRAFT –
MATF 15 October 2025

<JJ> zakim nominate a scribe

<JJ> zakim propose a scribe

<JJ> propose a scribe

<JJ> nominate a scribe

Second Draft backlog

<JJ> https://github.com/orgs/w3c/projects/147/views/1

JJ: has now been able to assign folks to issues on GitHub

1.4.1 Use of Color

<JJ> w3c/matf#262 (comment)

JJ: discussing comment on Note 1 of Use of Color SC

JJ: in understanding document there is an exception for only color if there is difference in hue then it's not considered only color

<JJ> 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

<JJ> 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).

<JJ> https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

<shoobe01> Yup, that even says invert. I have no concerns now.

JJ: reading the note about hue and lightness

<JJ> Poll: close the issue for 1.4.1 note?

<shoobe01> +1

<Tim> +1

JJ: add +1 or -1 for the poll

<pauljadam> +1

JJ: discussing that the issue needs to be linked to parent

<JJ> Poll results: 3x +1

JJ: enough today about 1.4.1

1.4.2 Audio Control

JJ: 1.4.2 audio control next on agenda

<JJ> w3c/matf#113 (comment)

JJ: discussing comment from mitchellevan about overall system volume

JJ: discussing comment android behavior where system volume control is different than talkback volume

JJ: discussing comment about different methods of changing system volume in android

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

JJ: this SC may be automatically passed due to android system behavior of controlling volume

JJ: discussing comment that mechanism must be widely available

<JJ> 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.

schoobe01: how do we write this up about the audio control capabilities of android without talking about specific mobile OS

JJ: W3C does not want us to be that specific in our guidance

JJ: maybe have a note that shows an example of how to meet audio control

pauljadam: talking about how this is not about screen reader volume it's about app volume and system volume

<JJ> Goal

<JJ> A page that plays music or sounds doesn't disrupt people.

<JJ> What to do

<JJ> If you play audio content automatically, let people turn it down or off.

<JJ> Why it's important

<JJ> Sound distracts some people, and also interferes with screen readers.

JJ: mentioned that goal is for users to turn off background sound and reduce volume to zero

Jamie: maybe we should hold off on trying to identify android and iOS specifics

Jamie: may not have much to change about this success criterion

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

<Tim> I agree with Paul

JJ: on iOS can't intercepts clicks on volume up or down button to adjust your app volume

JJ: if changing the volume affects other apps then it would not be a way to meet this SC

JJ: its reasonable to expect if people have auto playing audio they have a proper way to pause that

JJ: done for this sc for now

JJ: asking what are the actions related?

Jamie: whats the issue that would keep us from moving forward on this?

<JJ> 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"

JJ: added poll

<pauljadam> +1

<Tim> +1

<shoobe01> -1

JJ: add +1 or -1 or 0

<GleidsonRamos> +1

<Jamie> +1

shoobe01: concern is that it does not say only that app

<JJ> Replace "active app" with "overall system volume" / "app volume"

shoobe01: concern is not sure why system wide is bad

JJ: could say if audio does not affect overall system volume because that is aligned with the text

JJ: what do we consider over all system volume

JJ: if I change to another app and its also using the volume from the other app then its the system volume

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

ACTION: Reply to w3c/matf#113 (comment) 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"

<JJ> 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

JJ: discussing different ways AT users might adjust volume

JJ: sees benefit for in app controls vs using the physical volume buttons if AT user

Virtual keyboard definition

JJ: moving to next agenda

JJ: virtual keyboard definition does it need to be modified for use on mobile apps

JJ: reading shoobe01 comment about virtual keyboard on mobile, full keyboard access, external keyboard

<JJ> 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

<JJ> primary input method.

<JJ> 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. (!)

<JJ> 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?

JJ: virtual keyboard has to be software not hardware

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.

JJ: is on screen keyboard virtual keyboard or not

JJ: any more comments on this topic?

JJ: do we consider on screen keyboard to be virtual

I do

<JJ> +1

<pauljadam> +1

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

so I'm not sure that iOS keyboard actually generates keystrokes from a keyboard

Jamie: we're looking into definition written from WCAG2ICT and not WCAG

Jamie: is taking out the software piece tripping up folks

JJ: checking where virtual keyboard is being used

<JJ> note 5 of https://w3c.github.io/wcag2ict/#applying-sc-2-1-1-keyboard-to-non-web-software

<Jamie> should we take out the "software" part at the beginning

<JJ> and note 2 of https://w3c.github.io/wcag2ict/#applying-keyboard-interface-to-non-web-documents-and-software

virtual keyboard likely more a concern for WCAG2ICT like for kiosks but less an issue on mobile apps maybe

shoobe01: concern about keyboard, alternative keyboard, and virtual keyboard definitions

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.5.8 Touch Target Size

<JJ> w3c/matf#155 (comment)

<shoobe01> I will /have/ to leave 1-2 min before the hour, sorry I may miss some of this conversation then

JJ: reading comments on touch target size

JJ: showing the graphics that have different touch target sizes in the comments

<JJ> w3c/matf#10

JJ: maybe add some suggestions about not placing targets close to edge

<JJ> w3c/matf#10 (comment)

ACTION: Provide feedback on 2.5.5/2.5.8 research

shoobe01: discussing proposal to reword, in the comments

JJ: read through comments and share thoughts please in the issue 10

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

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

ACTION: Reply to w3c/matf#274 if you agree (thumbs up) or disagree (thumbs down)

JJ: nice to see progress we still have a lot we are closing some issues, making progress