– DRAFT –
MATF April 9, 2025

3.1.2 Language of Parts

<JJ> https://w3c.github.io/matf/#success-criterion-3-1-2-language-of-parts

<JJ> w3c/matf#15

JJ: Summarized background on 3.1.2 about feasibility of applying this SC. It is technically possible, but could be a burden for developers. Also, dealing with web content (use of <lang> passes the SC for web views).

<pauljadam> content can already describe everything

<pauljadam> it means it fails WCAG as a defect in the platform the platform developer must fix

JJ: WCAG2ICT replaced "content" with "non-web document or software" and added a note that some technologies don't support this and "may not be able to meet" this SC. Is "may not be able to meet" an exemption or a failure?

ACTION: Find out what "may not able to meet" means for 3.1.1 and 3.1.2

JJ: Android and iOS do allow this, though we need to map out other x-platform frameworks. But, is it a burden on developers? It seems to me that it may not be much worse on mobile than on websites.

<pauljadam> iOS SwiftUI a11y docs on Language of Parts https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/Language.md

AlainVagner: Not sure if it's a burden, but coming from a country with more than one national language, we often mix languages and it's a burden when you don't indicate the language. Feels like a loophole for mobile vs. what's available for web.
… I have a feeling it's not much more complex than indicating language on the web. There may be some cases where it's not possible, and for me that would be an exemption.

<pauljadam> It is the case that you can set the language for strings in a language different than the page. If something does not work then it's a platform defect failure that apple or google would need to fix. No exception to WCAG needed!

JJ: On Mobile, components must accept attributed strings or localized span.

<JJ> pauljadam > imagine a component that does not take NSAttributedString as argument, you won't be able to pass a localized string, even if the OS does support it (the component does not)

<pauljadam> Are well saying that "On Android you can't set the heading level so therefore you are exempt"? Because I would not provide an exemption, It should just be a generally understood rule that If you can meet WCAG here then you must, if you can't then your platform has a defect and apple or google need to fix it.

Jon_Gibbins: This reminds me of WCAG 1.0 days. Speech engines will detect a change of language on platforms, which doesn't mean we should not also give language info attached to strings. We're not just writing guidelines for Android and iOS, but for mobile as an environment. We should aim for the spirit of WCAG, and when the platform doesn't

support it, there's an exemption. But the work is on devs to determine what's possible.

<pauljadam> Man I wish we could use Slack for meetings and chats so I could edit my typos 🤪

JJ: I agree, we could use a note that there would be an exception for cases where the chosen platform cannot support the language.

<Jon_Gibbins> JJ: Agreed

JJ: We could take an approach like with 1.1.1 where the SC applies as written, but include a note that not all platforms support lang of parts.

pauljadam: I don't agree with the label and image not being possible on all platforms. I'm not a fan of adding notes that say "this isn't possible", what happens when the platform evolves and improves? It should be understood that devs need to follow WCAG and if they can't, that's a platform defect that Google and Apple should fix.

<Jon_Gibbins> PaulJAdam: Agreed on notes. We can capture platform specific detail on any supporting understanding documentation.

JJ: Part of our work as MATF is to point out instances where there may be technological barriers. The note for 1.1.1 is to address expected behavior where someone might focus on an image, the caption below would be read.

<pauljadam> what about when a new mobile OS comes out, ChatGPT mobileOS

<Jon_Gibbins> For clarity, my point about WCAG 1 was in having a common phrase that we use to refer to situations where we know that certain platforms are currently lacking *without* refering to specific platforms in this guidance document of ours translating WCAG2ICT.

JJ: During the last CFC, a question of scope came out and we do need to clarify the platforms we're considering in this doc.

As for updates, the major platforms get updated once a year, it seems reasonable to update WCAG2ICT once a year if needed.
… We could make a distinction between general guidance and more specific notes that apply to Android or iOS

<Jon_Gibbins> For reference: https://www.w3.org/WAI/Resources/WAI-UA-Support

<Jon_Gibbins> Joe_Humbert +1

Joe_Humbert: I think we do need to have notes, but based on CFC feedback, we should try to make notes as generic as possible so that they could cover other devices/OSs besides Android and iOS. We've done a decent job where notes do apply to Android and iOS but they could apply to other OSs.

JJ: Maybe we should keep track of which notes target which platforms. LIke the 1.1.1 note mostly applies to iOS.

<pauljadam> That note makes me worry that a developer would see that and say "Oh we can't make labels accessible but have an exception".

<pauljadam> The note is not accurate, I can code an example with a programmatic label.

Joe_Humbert: Maybe we include an example as part of the note.

JJ: This might help for OS-level considerations, like known examples, since Understanding docs are off the table for the moment.

<pauljadam> I think talking about what is possible can be done in Mobile Techniques rather than the notes that say what is Not Possible.

JJ: Re Paul's comment about the label, it's perhaps not the best example because there are workarounds. 3.1.1 would be a better example.

ACTION: Mention platforms in the notes, e.g. it's known that on Android certain functionality is not available, while keeping the note generically applicable to more mobile operating systems

Jon_Gibbins: I agree with Joe and Paul's comments about making this doc cover as many bases as we can, not being overly specific about platforms. There's an opportunity and a danger: Opportunity to educate developers, but it's not the doc's job to provide specific platform techniques.
… To the 1.1.1 note about labels, we have to be super careful about vocabulary we're using because it's WCAG terminology.

<JJ> Jon_Gibbins: We have to be very careful with WCAG (web) terminology in our mobile application guidance to avoid confusion / wrong expectations

Jon_Gibbins: We can link off to existing resources on techniques like Appt or the iOS techniques repo. We have to be clear that in this example an accessible name is a label, not a label-for. Or we can add a note that we are talking about a label and it doesn't mean accessibilityLabel or Content DEscription.

<pauljadam> If WCAG can have PDF Techniques, Silverlight techniques. I'm not sure why we can't have Mobile Techniques 🤷‍♂️

<JJ> Because those techniques can be used on the Web, and mobile apps are 'Non-Web' :/

<pauljadam> Mobile apps live on the web as far as end users think of it. HTML is the web and Mobile is the web.

Jon_Gibbins: In our notes, we're not saying that an SC doesn't apply, but that there may be issues in applying it. We should be careful with what we put in notes.

<Tanya> Was is ever considered to add a note something like "if there are constraints or limitations set by the operating system, the implementation should follow the best possible or closest alternative that meets the intent."?

JJ: We have a wide audience -- accessibility professionals, developers who are familiar with WCAG, developers who are new to WCAG. Also, I want to revisit the expand/collapse mechanism, will people actually read their content?

<Jon_Gibbins> pauljadam: WCAG does not have techniques in it. The supporting Understanding documents do.

3.2.2 On Input

JJ: To summarize, we agree that this SC applies, given that it's technologically possible for the platforms. We may need a note to clarify.

<pauljadam> Ok mobile techniques need to go here too https://www.w3.org/WAI/WCAG21/Techniques/

<Jamie> Did I miss a vote?

<Jon_Gibbins> pauljadam: I agree, eventually. What I was saying is that, until such time as we can work on understanding and techniques documents (currently beyond our group’s remit, I believe) linking to examples may be the best we can do for now.

JJ: Summarizes 3.2.2, including need to define user interface component and change of context.

JJ: Further definition also required for "changing the setting"

<JJ> https://w3c.github.io/matf/#success-criterion-3-2-2-on-input

<JJ> w3c/matf#42

<pauljadam> That is failing WCAG to auto submit the form unless they are warned of the behavior before hand.

<pauljadam> How do they know

<pauljadam> you must tell them

julianmka: Common pattern where a one-time passcode is automatically submitted after the user enters it. Seems to be commonly done and has sort of become expected behavior.

JJ: Right, do we need to inform users if it has become an expected pattern? Users seem to understand that the PIN screen will submit.

<Jon_Gibbins> I have seen this in autocomplete widgets, but mostly on web and I admit rarely on mobile. Sometimes, developers assume that moving focus on behalf of the user to search results is necessary, which is horrible when typing into an autocomplete.

<Joe_Humbert> on android the auto-submit is a user option

Tanya: We see forms changing content after selecting a checkbox and fail that.

JJ: On Android or iOS, when you enter the PIN and it is automatically submitted. Some people were confused when they had to press a button after entering.

<pauljadam> Just a simple text message above the input warning of the behavior is all that is required.

JJ: For Android and iOS, have users been informed of the behavior during onboarding?

<pauljadam> That would be a perfect mobile a11y technique :)

Potentially we could use a note if it's common behavior. It's up to auditors to decide if the user has been sufficiently informed.

JJ: We have one client who added a Submit button. But maybe you could have have some text on the PIN screen advising that the code will be automatically submitted.

<pauljadam> "common behavior" is not the same as "the user has been advised of the behavior before using the component."

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

<pauljadam> DOB split into 3 inputs is another somewhat common example

ACTION: Potentially add note about pincode screen auto-submit behavior?

<pauljadam> Usually these are web views and they would be text field inputs

<pauljadam> usually it will be text fields that are made to accept the passcode automatically like with auto fill

JJ: On iOS, there's also specific code to pick up the one-time passcode from messages or email, and it autofills the code and automatically submits the form.

<Jon_Gibbins> JJ +!

<JJ> https://github.com/w3c/matf/issues?q=is%3Aissue%20state%3Aopen%20label%3Adefinition

JJ: Mostly we need to focus on definitions for change of context and user interface component. I suggest that we propose specific definitions to the group and discuss them in our meetings.

<Jon_Gibbins> JJ +1

TF members, please add yourself as an assignee to the definition issues in Github.