– DRAFT –
MATF 29 January 2025

<JJ> Starting in 2 minutes

<quintinb> Thanks Detlev

WCAG2Mobile update

JJ: Working on drafting new text for guidance (shares screen)

JJ: (Reading out SCs with small variations)

<JJ> https://github.com/w3c/matf/pull/82/files

JJ: Check if you have access to GitHub to comment - need to be part of MATF, nocht just AGWG

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

JJ: (sorts issues by lable drafting)
… please comment if you have issues
… on GitHub
… Jamie has been woring on Abstract and Info / Background, Scope, Status
… comparison with old Note
… replacing pages with "view"
… what is and what is not in scope
… not doing wearables / watches

<JJ> https://github.com/w3c/matf/pull/83/files

JJ: Soon getting ready to go for first publsihed working draft
… any considerations what should be added?

new participans: Tanja & Rob

Tanya: introduces herself - working at Abra with JJ
… focus was audits of mobile apps
… many questions of interpretation - have followed MATF discussions, wants to provide input from audits
… want to reach consensus how to approach issues, find common interpreatations

Rob: iOS dev focused on a11y side of things worke dfor large customers, wants to get mobile devs interested in a11y
… make sure that guideline sare understandable to people who are not super experts or haven't worked on webv

1.3.5 Identify Input Purpose

JJ: (pulls up github issue for 1.3.5)

JJ: we are nt using the chat in Zoom but in IRC
… Zoom comments won't be minuted

JJ: one issue in apps is that it is different from setting input purpose, also harder to determine (no source code access)
… so how can we audit this?
… some properties are available on Android but not iOS
… you can set the keyboard type, that gives some indication
… sometimes possible to identify auto-fill property
… Joe did some research on auto-fill
… Detlev comment that auto-fill is just side effect comment

JJ: (reads out WCAG SC)

<JJ> https://www.w3.org/TR/WCAG22/#input-purposes

<JJ> https://w3c.github.io/matf/#success-criterion-1-3-5-identify-input-purpose

JJ: list of input purposes (via autocomplete)
… reads WCAG2ICT note on not supported attributes

<quintinb> You can do this in android using the input type: https://developer.android.com/reference/android/text/InputType

JJ: reads note 2 (eqivalent terms - but in iOS and Android they would have different names)

JJ: was considered large variation - any further thoughts?
… what would pass, what would fail?

quintinb: LInk to Android-defined input types - should devs use that interface?

JJ: (shows equivalent for iOS)

quintinb: can be be tested by looking at keyboard and the types of inpu in field (say stars for password)

<JJ> iOS equivalent: https://developer.apple.com/documentation/uikit/uitextinputtraits/textcontenttype

Tanja; We don't test it in audits so far - lacking unified approach - it should be clear how it can be tested, so that leaves room for interpretation

Tanya: Nit clear how it can be tested in standardised way

Sorry Tanya!!!

<Jon_Gibbins> I’m sure I have a link to an equivalent list of Input types for iOS, but can’t find it currenly

<Jon_Gibbins> Ah ha! JJ has posted it!

JJ: showing appt.org resources for 1.3.5

<JJ> https://appt.org/en/guidelines/wcag/success-criterion-1-3-5#solution

JJ: different names in different development frameworks...

Gleidson: apply to the limit possible in cross-platform environments
… if technologies do not provide these attributes, content should pass

JJ: How to deal with it if the native environment does support it, but a framework like flutter does nt support it?

JJ: Saying it FAILS may incentivise platform developers to extend support

<quintinb> Topic 1: Ensuring that these get exposed by the accessibility tree is important for "programmatically determined"

<quintinb> Topic 2: I am also less likely to be considerate of cross platform, they need to support the native platform, not the other way around. The AT is native and XP needs to acknowledge the user, not the user the XP

<Jon_Gibbins> I feel we’re veering into the area of content versus user agent here (WCAG versus UAAG). Like WCAG/WCAG2ICT, we are likely to have to consider exceptions for third party software / cross-platform frameworks, etc.

<Jamie> +1 quintinb topic 2

quintinb: we can't sit and wait if some lazy platform does not support some attribute

<GleidsonRamos> I agree. We need to at least try to force the cross-platform techs to accomplish the criterias.

JJ: tends to be stricted and FAIL it to increase pressure on frameworks

<quintinb> I'm also just as critical of Google / Apple if they don't provide stuff, but XP needs to ensure it's up to date with the OS at least

<quintinb> +1 Jon_Gibbins re: WCAG versus UUAG

Jamie: Section 7 in WCAG is referenced in WCAG WCAG2ICT says applies as written; but we need to take a closer look to see if that id fine for us in the native app context. We are discussing variations already, so as written may not cut it. So we may need a change in the normative wording?
… some of these items in sction 7 just don't appl yto th enative dv context
… we may add a section like section 7 of WCAG that fits better

JJ: Seems strange that WCAG3ICT add a note linking to the same section that is not directly applicable to non-web

Jamie: so there could be a WCAG2ICT version of section 7 - and we should something that covers the mobile context

JJ: since we are non-normative we could create a link to a more appropriate understanding section

ACTION: Decide how to deal with "WCAG 2 section Input Purposes for User Interface Components" and the WCAG2ICT (redundant) note

Jon_Gibbins: We get more situations like that with mobile conditions - so it may need conditions or things like "until platforms.."
… is it a problem with AT or platforms so we may need something "Until platform supports" .. we ca ncreate a vision but we need to be mindful at who has control here . devs may have no control so it would be out if scoe for them, because this is for peopl ecrating the software - so it may address other players like th eOSs makers, platform makers

etc.
… we should acknowledge that cross platform environments have their issues

<quintinb> Slippery slope to escaping regulation: "We did it in Flutter"

JJ: harks back to our definitions, like keyboard interface

<Joe_Humbert> everyone else covered my comments

JJ: we need to be careful drafting definitions - different from HTML context where many things are already accessible
… doing things in REACT it will be limiting, there is less control

<Jon_Gibbins> I wrote exceptions – I meant “conditions”. To sumarise for meeting notes: I feel we’re going to come up against situations on mobile a lot where cross-platform frameworks / platform software may not support something, but the focus for WCAG2Mobile should be on what the people creating native mobile apps have control over. In the past we’ve seen statements in SCs like “Until user agents…”.

<JJ> Jon_Gibbins - that also applies to 1.4.12 Text Spacing as Android/iOS currently don't offer such settings; but might in the future

<Jon_Gibbins> +1 on clarity of definitions. I’ve been doing work on definitions the last couple of weeks which is where my thought came from.

Jamie: Question about SC for language - can we modify the documentation referenced, or can we modify the SC itself (talking about 1.3.5)

<quintinb> Back!

JJ: the idea is: If there is an input purpose that is listed in section 7, then provide programmatic identification. So if we shortn th elist it would exclude some input purposes

<Jon_Gibbins> “Until user agents…” statements are from the days of WCAG 1.0. The equivalent terminology in WCAG 2 I believe is “accessibility supported” https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported

Jamie: Acknowledges that the context matters, not the exact keywords - we may need to brinf that back to the AGWG

JJ (writing action)

ACTION: Check with AG WG and WCAG2ICT how they intended the Input Purposes section and why it's directly in WCAG(2ICT)

JJ: any further tasks for this SC?

<JJ> move to the next agendum

1.4.4 Resize Text

JJ: Reads out WCAG text for 1.4.4

JJ: Reads out WCAG2ICT and note

JJ: note refers to platform options for text scaling (Zoom)

<Jamie> can we add "nonlinear scaling" to the terms list?

JJ: reads out note that some text may not scale fully to 200%

JJ: Side effect of replacement user agent > platform is that in native context the OS zoom function would be sufficient

JJ: Discussion in WCAG2ICT github, result is that OS zoom would pass
… Android scaling is not linear (large text scales less)

<quintinb> Does this mean that you can fix font sizes and as long as the magnifier service magnifies, that's acceptable?

<JJ> w3c/matf#3

JJ: So one of the issue is what can be exempted in native apps when text scaling

JJ: We may need a note on large content viewer (iOS) as method tzo comply

<JJ> close the queue

Jamie: One issue in the wild is exceptions for some copmponents in mobile apps, some component types don't scale - we should cature what components can scale and what othe rcomponents can't

JJ: Yes we should point out thosde limitations

<Jon_Gibbins> +1 Jamie, although we need to be careful that behaviours may change rapidly, so should form part of non-normative text (e.g. understanding)

Joe_Humbert: We should be careful - the large content viewe in iOS has no equivalent in Android - so you may need an equivalent in Android

<Jon_Gibbins> Or perhaps such differences in support or behaviours can be in SC notes?

<Joe_Humbert> thank you Detlev for scribing

<quintinb> Thanks all, and especially Detlev for scribing!

WOnder it scaling issues would ever FAIL anything if OS zoom is considered sufficient...

<JJ> We might also need more emphasis on the scenarios mentioned in Understanding doc

<JJ> "Some user interface components that function as a label and require activation by the user to access content are not wide enough to accommodate the label's content. For example, in Web mail applications the subject column may not be wide enough to accommodate every possible subject header, but activating the subject header takes the user to the

<JJ> full message with the full subject header." https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html