– DRAFT –
MATF May 14, 2025

Joe_Humbert: JJ off today

1.3.5 - Identify Input Purpose

Joe_Humbert: (sharing screen)

Joe_Humbert: Discussed before in GitHub issue and call

Joe_Humbert: topic what attributes are available natively

Joe_Humbert: reading purpose from WCAG

Joe_Humbert: WCAG2ICT says it applies as written - with note on lack of attributes specifying purpose

Joe_Humbert: other topics about testing - difficult using user-based testing

Joe_Humbert: did some testing - autofill in Android, some date showed up, other data didn't

Joe_Humbert: autofill is only side effect

Joe_Humbert: action to check with WCAG on intended application to software - why is it directly applicable in WCAG2ICT
… how does list in WCAG 2.2 apply to native

Joe_Humbert: no clear equivalent in native environments

Detlev: Does keyboard change?

Illai: In the light parsing SC removed, keychain in iOS similar in Android - is this really required?

Joe_Humbert: on Android & iOS - keychain does not identify required input
… unclear what heuristic are used to drop data from keychain int field

Illai: maybe not worth digging into it because OS is taking care of it?

<Carol> We can use the autoFillHint for Android native

<Carol> https://developer.android.com/reference/androidx/autofill/HintConstants

<Jamie> =

Detlev: Fills in background of 1.3.5 in the web context and lack of implementations
… for presenting appropriate keyboard it is useful

Joe_Humbert: The keychain to autofill date can also be helpful

jamie: Looking at WCAG section 7 - some things would apply conceptually - might be applicable eleswhere

<Joe_Humbert> w3c/matf#2

<Joe_Humbert> https://www.w3.org/TR/wcag2mobile-22/#success-criterion-1-3-5-identify-input-purpose

Joe_Humbert: A note for practical ways to test would be useful

Joe_Humbert: (summarises notes from WCAG2ICT)

Joe_Humbert: Do w estill thin it applies as written (with WCAG2ICT notes)?

Illai: Too many unknowns if we have equivalents

Joe_Humbert: Do we need to identify known equivalents

<Carol> https://developer.android.com/reference/androidx/autofill/HintConstants

Carol: There are purpose equivalents in Android

ACTION: Need to research section 7 equivalents on iOS and Android

Jamie: It may not cover all of them - at least it remembers user name

<Carol> autofillHint and importantForAutofill property for ANdroid

<Joe_Humbert> section 7: https://www.w3.org/TR/WCAG21/#input-purposes

Detlev: all that might be available right now does not map onto the original intent of the SC

Joe_Humbert: all applies to autofill

<julianmka> https://appt.org/en/guidelines/wcag/success-criterion-1-3-5?framework=swiftui

julianmka: appt.org has done some research on content types - autofill hints for Android
… we can go off that

Jamie: what needs to be resolved from the action item?

Joe_Humbert: (relating histor of SC and relation to autofill side effect)

Joe_Humbert: So we ask: is there at least an equivalent to the autcomplete attribute

Jamie: yes there are

Joe_Humbert: we can write a second action based on the first one
… to vaildate pass fails?

Jamie: What do we want to resolve?
… this gives an update to section 7

Joe_Humbert: we want to determine if WCAG2ICT is good enough or need modification - if no one has further comments, we can move on to next

<Carol> new guide on how to test them

<Aash> +1

<Carol> +1

<AlainVagner> +1

Detlev: add note about displaying custom keyboard for input types

<julianmka> +1

<rachaely> +1

<Jamie> +1 note

ACTION: Draft note about custom keyboards or keyboard that change to match the required input

Detlev: takes action to draft a note for customise keyboard

<Jamie> +1 to accepting WCAG2ICT version of 1.3.5 with an update to Section 7 of WCAG

julianmka: should we add a link to the page at aapt.org

Jamie: why not put those things in our own sectino 7?

Joe_Humbert: these things change over time - updating problem

julianmka: we could have links to the platform api pages as well

Joe_Humbert: we need to check our policy / retrictions regarding external non-standard 3rd party links

Jamie: There are a lot of those links in Understanding docs

Joe_Humbert: This may be OK for understanding - maybe not for notes

ACTION: ask WG about linking to appt.org or other 3rd party documentation

julianmka: maybe we submit an addition to the understandig docs to cover variation

julianmka: There have been changes / updates that have acknowledged mobile issues and variants

Joe_Humbert: Most of those addressed mobile web
… same in MAT slack channel

Joe_Humbert: openness to have techniques, less so in common understanding docs? We can enquire abnotu that

1.4.4 - Resize Text

Joe_Humbert: Very large topic

Joe_Humbert: (reading WCAG text, WCAG2ICT text)
… "without use of AT"

Joe_Humbert: Discussions were about viewport size, device specific text size settings and scaling behaviour
… supporting OS specific AT settings

Joe_Humbert: note on timeline for supporting features
… discussion on whether mobile is exempt from 1.4.4 (pending on the meaning of AT)
… requesting clarificatino on defining what counts as AT

<rachaely> +1 to defining Assistive Technologies

<Joe_Humbert> w3c/wcag#730 (comment)

Joe_Humbert: JJ commented based on issue response that on native mobile, system zoom would be a way to pass 1.4.4
… also added info on sizes styles available on native mobile
… there was discussion on large content viewer in iOS
… concern on too much detail on techniques since tech changes quickly

<Joe_Humbert> w3c/matf#3

Joe_Humbert: mostly about the line what is AT, what isn't?

<Joe_Humbert> close the queue

julianmka: We can lean on the fact that text resizing has robust support in OSs so that is what people need to do

Joe_Humbert: Greggs distinction still does not give full clarity regarding what is AT

Joe_Humbert: More clarity on product segments on desktop, less for mobile

<Jamie> congrats to Joe_Humbert for leading

<Jamie> er thank you

<Joe_Humbert> Continue discussing SC 1.4.4 Next meeting