– DRAFT –
MATF 5 February 2025

<Illai> פרקדקמא+

I thought it meant we'll get a present

Don't be smart Illai

:P

WCAG2Mobile update

JJ: Please review the PR's on GitHub!

<JJ> https://github.com/w3c/matf/pulls

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

Jon_Gibbins (Update on key terms): First pass on wcag2ict keeping in mind previous discussions. We've put notes so please have a look, we need to agree on definitions. The next step is to review and create the glossary. Jamie has helped. These are 1st draft - Would like it to be done for next week. RFC on these terms, will be updated with context.

Jamie (Update on key terms): Please take the opportunity to comment. How are we modifying the WCAG2ICT terms for how they relate to mobile and which key terms need to be added just for mobile 2 wcag conversation. WCAG2ICT pulls out new words in a key terms section, so we should do the same

Jon_Gibbins we may need to be careful on how these terms relate to each other, and some key terms need new key terms

JJ WCAG is trying to remain platform agnostic and perhaps we should take the opportunity to make sure people are on the same page

JJ we need to ensure we are consistent (e.g. replacing Keyboard with Assistive tech)

:O

1.4.4 Resize Text

Also Android lets you define really awful text spacing

1.4.4. should not require the use of a specific assistive technology

Detlev Are we all in agreement that zoom alone is sufficient to pass. It's not best practice, I would not agree that it's not clear. Be careful with that statement

I think we just need to be careful that we don't get prescriptive about specific AT

JJ reads 1.4.4 "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. " - note that it's without the use of AT

Jon_Gibbins My understanding has always been that it's without AT. The reading has been changed to actually be explicit in not requiring a magnifier. It does mention this in the understanding doc

Jon_Gibbins I think we should continue that in the mobile guidelines. We need to use WCAG as the original intent

Tanya it feels to me (the definition of zoom) - it means something different. In web zoom intends to do something different than a magnifier. It seems that screen zoom and magnifying from a function perspective is a bit confusing. The definition needs to be more broad.

Jon_Gibbins these guidelines are for the builders and the responsibilities on them. Zoom works indepently of the development. Font size is within the control of developers. A solutions perspective is fine, but these guidelines are aimed at buildersa

<JJ> WCAG2ICT comment: w3c/wcag2ict#4 (comment)

<JJ> "Point 3: We've long held that PC magnifier programs are assistive technology and therefore not a method of meeting 1.4.4. Is the same true on other platforms?

<JJ> TF Answer to Point 3: For Non-Web Documents and Software, features including software provided by the platform that provide a means of enlarging the text 200% (zoom or otherwise) without the loss of content or functionality, meet the intent of this success criteria.

<JJ> Platform accessibility features, including platform software that, when applied, causes loss of content, including a reduction in the ability to distinguish characters, would not meet this success criteria."

Joe_Humbert We might need to bring this back to WCAG2ICT because the linked issue has a conflicting statement in the note (w3c/wcag2ict#4 (comment)) there is an answer to point 3... it does seem to conflict the draft. The draft says in note 1 that the application provides some means... I'm confused because

they answered the question then changed it in the note

<JJ> Versions of WCAG2ICT: https://www.w3.org/standards/history/wcag2ict-22/

Detlev A comment on Jon_Gibbins - I think looking at WCAG there are many cases where something should be possible for the user. There are different options available. Sometimes the author doesn't need to do anything in order to pass. It's not uncommon that the author doesn't need to do anything to ensure things are available to users, which may be

the case in terms of font scaling

<Jon_Gibbins> “Zoom” as a feature is a bit ambiguous – and I’m uncertain that WCA2ICT discussion is referring to Magnification AT. “Zoom” on a web browser is different to, and behaves differently to “zoom” accessibility features of a mobile OS.

JJ let's continue the discussion on GitHub

<Detlev> if you requre text scaling you end up with many situations whee not all text scales - and where do you draw the line then if something passes or fails?

<Jon_Gibbins> I’d just be worried about suggesting to mobile app developers that it’s okay to not support dynamic type because users can just use magnification. (Noting that we are focussed on mobile, and for broader ICT the story may be different – kiosks for example.)

jamie: Do we need something here on custom components and system font sizes to account for authors using custom font sizes.

<julianmka> +1 Jon

Joe_Humbert do we need a vote / discussion on where Zoom fits in?

Jon_Gibbins if Regex is your solution, you have 2 problems

ACTION: Create issue for terminology used in Android and iOS for Zoom related functions

<Jon_Gibbins> quintinb: Haha - habit. Sorry.

:D

Jamie: Did we talk about hybrid content and how to interpret zoom for hybrid content. for e.g. reactive native let's you use system sizing or other platformsa that allow pinch to zoom

2.1.1 Keyboard

pauljadam introduction

I can testify that Switch, Keyboard and Screen readers on both Android and iOS behave entirely differently

Phones are personal devices, in my opinon you can plug a keyboard in if you want to

<JJ> w3c/matf#12

Thoughts for Keyboard interface: BLE / Serial Cable

"Standards" help a lot

<JJ> Yes defining the "interface" that's used to send the "events" could help to scope the technologies that use the keyboard interface

<Jon_Gibbins> “Keyboard focus like behaviours” would perhaps encompass switch access, for example.

<JJ> For Switch Access there are also a lot of different input devices, e.g. actual switches, but also blinking, etc.

<Jon_Gibbins> But a “virtual keyboard” which is a keyboard like interface isn’t really used for navigation? But it is used for input.

<julianmka> Complicating the virtual keyboard, it can sometimes allow navigation -- between form fields or as a submit button (depending on how the screen's been developed, of course)

<Jon_Gibbins> From an AT point of view, I’m thinking screen readers mainly, we have the virtual cursor versus what I call “input focus” in mobile environments.

<Jon_Gibbins> julianmka: Good point

<Jon_Gibbins> I wonder if “keyboard” is for “input focus” behaviours (like when separating Meaningful Sequence from Focus Order)

<Jon_Gibbins> I’ll save comments for the GH issue :)