W3C

– DRAFT –
MATF 1 July 2026

01 July 2026

Attendees

Present
Detlev, Joe_Humbert, jwlilly, pauljadam, shoobe, shoobe01
Regrets
-
Chair
Tanya
Scribe
quintinb

Meeting minutes

Success Criterion 2.5.3 - Label in Name

Success Criterion 2.5.8 - Target Size (Minimum)

move to previous agendum

Fixing problems I created

Detlev: I think the difference here is some thing that is mainly more common for apps is that you have these complex components like tiles or cards that have several interactive elements, so it's not clear what the label is - the problem is knowing which elements should get a name. There are several names that need several focus stops that each

need a name or make them available through actions. If you have a card where labels are spoken one after another it can be incredibly confusing. It would be a disservice to people evaluating content if we didn't include it

pauljadam it seems like it's going beyond the normative success criteria, this is just different values for the control. It's a lot of usability criteria like braille. I wouldn't put it there and put it in an understanding document. Maybe compare the difference, I don't know how you'd put it all into a note

jwlilly my includion of the picker and braille was kind of an argument against in the full accessible name - it's not necessarily something I think we should include in the note. I am fine with including it in the note in the understand or in the technique. Because it's fundamentally different from web it seems like it's something that would come

up regarding mobile apps

pauljadam it's a preference to have really long alt text

pauljadam if I was to change something, I would make it a best practice to have the label at the beginning, and explain why. This SC is more about voice control and we seem to be focused on screen reader

Detlev - this should be the other way around - it's not wrong to have a very long accessible name technically. As long as the visible name is in there. It would be bad practice not so much for voice control,, but for screen reader users. The point that the visible label at the beginning - at the moment it just has to be included somewhere, making

it useless, but it's embedded in WCAG.

<pauljadam> https://developer.apple.com/help/app-store-connect/manage-app-accessibility/voice-control-evaluation-criteria

pauljadam just to mention apple's nutritional labels have a voice control evaluation, where the label needs to be in the (i forgot the other one) - but that's why at CVS we go beyond WCAG

name - jeepers

pauljadam everyone has a different preference - apple used to have many sentences, now you only see the first word, and still numbers are faster

Poll: Do you think we need to extend note one with an explaination of best practice (1 - yes, 0 -no)

<pauljadam> +1

<quintinb> +1

<Tanya> +1

<Detlev> +1

<jwlilly> +1

<shoobe01> +1

<Joe_Humbert> +1

ACTION: extend "Label in name" note one with an explanation of best practice

Poll: Do we need to move note 2 to an understanding document? (1 - yes, 0 - no)

<Detlev> 0

<pauljadam> +1

<jwlilly> +0

<quintinb> +1

<shoobe01> +1

<Tanya> +1

<Joe_Humbert> +1 just too much disagreement in the group to keep

ACTION: move note 2 to an understanding document

Success Criterion 2.5.8 - Target Size (Minimum)

shoobe01 No mostly done and looking for feedback - discussion of pixel sizes needs some re-working, I don't like dip. I need to double check other OS's to make sure we get everything uniform. I was trying to avoid being OS specific.

<pauljadam> can you just say 24 x 24 and leave out the "px" ?

shoobe01 I can put in specifics, but I was avoiding that

I wanted to answer pauljadam's question - you can identify the pixel units, but things get very tiny. I think excluding the unit is a bad idea - we should give developers a reference to make it easy for them.

We could always give them a pdf to print and let them cut it out

shoobe01 do we need be explicit on certain sizes

jwlilly - we should include a platform specific reference for them in terms they understand

<pauljadam> in code on iOS you just write midWidth: 24, minHeight: 24 so you don't add pt or px

pauljadam lucky

shoobe01 I forgot to point out - what terms are we using for referring to this - MATF Group Note Draft? Is MATF right? If you don't know we need to keep it in mind

shoobe01 should MATF be in the wording or WCAG's term for mobile?

Success Criterion 3.2.2 - On Input

lol - On Input, taken up

<pauljadam> Understanding page for that SC says "This behavior of phone fields is described for the user at the beginning of the form."

<pauljadam> https://www.w3.org/WAI/WCAG22/Techniques/general/G13

<pauljadam> Examples

<pauljadam> A select dropdown at the top of a page includes options for German, French and Spanish. Instructions preceding the dropdown instruct the user that the language will be changed upon selecting an option.

<pauljadam> A 50-question online survey displays one question at a time, with each answer marked up as a toggle button. Instructions appear at the beginning of the survey that explain that users will be taken to the next question of the survey upon selecting an answer to each question.

Joe_Humbert I don't have examples off hand. User are advised of behaviour beforehand - I need examples from a mobile perspective

Joe_Humbert if you can give me examples I'll update the language

Joe_Humbert are those app patterns?

pauljadam one example is for date of birth - it automatically jumps across fields

Joe_Humbert are those specifi mobile app examples?

Joe_Humbert I don't see the point of adding generic examples

pauljadam I don't see how we need to tweak it for mobile

Joe_Humbert The request for examples was because people may not have mobile specific examples

pauljadam there may be confusion around context versus content - that they need to warn the user before. That's not really required.

Joe_Humbert If you look at change of context does have content change

pauljadam only if it changes the meaning of the page

pauljadam it's not well defined

Joe_Humbert That's a larger problem - it seems we don't need examples - I guess we can call it good

Joe_Humbert the intent section doesn't have an id for me to point to

<pauljadam> a new mobile / modern example could be the 2 factor authentication code where when you type all the values then it automatically submits I guess that would need a warning before hand right?

Detlev do we need to think of the case of things like radio inputs behaving like buttons - like controls that create an expectation and then a change of context happens, but for something like a radio and in a range of questions when an option is selected it changes the screen, but it's not ok if it's a radio (ok for a button)

pauljadam that sounds like an example in G.13 - when clicking an answer it goes to the next page

pauljadam if you need a modern example - 2FA is an example, when you type the last digit it auto-submits

I hate that pattern, pauljadam

(on a personal level)

<pauljadam> quintinb well it does save you time so if there is a warning and it makes things faster for the user then seems fine to me :)

I love it when it auto-copies from messages!

<pauljadam> Like when apple auto pastes in the code then it submits and you dont have to click the submit button

aww yeah!

<shoobe01> Yes, I'll take help with scope of discussion for #247. Not sure what all is available as options but happy to write once I get that.

<shoobe01> Maybe collaborate with someone else?

Yeah add me to it - I'll add some comments

Summary of action items

  1. extend "Label in name" note one with an explanation of best practice
  2. move note 2 to an understanding document
Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

Maybe present: Poll

All speakers: Detlev, Poll

Active on IRC: Detlev, Joe_Humbert, jwlilly, pauljadam, quintinb, shoobe01, Tanya