– DRAFT –
MATF 21 May 2025

1.4.4 - Resize Text

<pauljadam> Screen Magnifier is an Assistive Technology. Text Size setting is not an AT.

JJ summarizes what has been discussed last week. Definitions, system zoom, definition of AT as a key of what can be used to pass.

<pauljadam> Apple considers Larger Accessibility Text Sizes as an "accessibility setting" NOT an Assistive Technology.

<pauljadam> Do we need a note to encourage authors to enable text scaling up to the maximum possible size on the user's device?

JJ JJ reads normative text, available definitions and notes; points out the difference between mainstream users and users of AT.

<Jamie> @Paul I'd say no

<pauljadam> Or some note about how it's hard to know when you are at 200%?

<GleidsonRamos> +1 about the note on how hard it is to know what is 200%. Dynamic scaling make that's harder

<pauljadam> I agree about the Large Content Viewer we may want to mention that also

pauljadam Do we need a note how its hard to know whether the text is scaled to 200%

<JJ> Tanya can you add ":" after the name of speaker, will look nicer in minutes :) e.g. JJ: blabla

RobW: you don't always get to 200%, so you would argue if it would ever pass. Users care that it works.

<RobW> you could scale text in bars, but that would be the wrong thing to do.

Jamie: asks whether we need to consider and how to approach the topic of customization of the fonts

<pauljadam> Pinch to zoom would only be allowed on a web view inside a native app.

<pauljadam> There is also a way to make web views respect the user's text size preferences with special apple CSS.

<pauljadam> Some apps will disable pinch to zoom in their web views which would be an easy fail if they're not supporting the user's text size preferences.

JJ: this SC was intended for web where you have zoom function and everything will scale without truncation. On iOS and Android it's working differently. Pinch-to-zoom will not be allowed on mobile. Web makes some things a lot easier.

<pauljadam> Screen Magnifier would never be allowed to pass this SC.

<JJ> https://w3c.github.io/matf/#success-criterion-1-4-4-resize-text

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html

<pauljadam> Zoom is not ok

Illai: intend of this SC is not limited to zoom or other techniek. Zoom is okey.

<pauljadam> WCAG defines screen magnifier as an AT

<RobW> I can't agree that a screen magnifier can be used to pass this SC

JJ: we need to have a definition of AT

<Illai> pauljadam the reference is to the user agent Zoom (control +, or command +)]

pauljadam: resize text is accessibility technology. Developes can ignore this all and not nothing at all

JJ: display scaling can be a way to pass. I feel like magnifier is an AT

Jamie: question of accessibility vs usability

<pauljadam> I don't think the iOS Display & Brightness > Display Zoom setting would be considered an Assistive Technology either.

<RobW> Agreed with PJA

<Jamie> @Tanya specifically "loss of content or functionality" identifying accessibility / 1.4.4 failure vs non-WCAG UX design

<pauljadam> Yes agree that the user's text size preferences should be respected!

<JJ> Tanya: do we agree as group that user preferences should be respected?

<Jamie> user preference = OS settings, not specific %

<pauljadam> That's what the user's expect. All sizes should work.

JJ: Apple will introduce a11y nutrition labels, where developers can document a11y features that the app supports. For auditors it means that they can test mentioned a11y features

<pauljadam> We may need a note about authors putting in the effort to have good readability and layout at the maximum text sizes, like if there is only 1 or 2 letters and lots of text hyphenation - showing then it's not very readable and they need to reflow better, e.g., reflow into 1 column rather than 2 columns. So you can pass WCAG with very hard to read

<pauljadam> large size text as long as it's not truncated but there should be an effort to make it visually easy to read at max text sizes.

<JJ> Jamie: Upcoming apple features: https://www.apple.com/newsroom/2025/05/apple-unveils-powerful-accessibility-features-coming-later-this-year/

Jamie: https://www.apple.com/newsroom/2025/05/apple-unveils-powerful-accessibility-features-coming-later-this-year/

<JJ> Low Vision TF: https://w3c.github.io/low-vision-a11y-tf/requirements.html#text-size

ACTION: Define "assistive technology"

Jamie: in mobile context we can considered a minimum size, which can be AAA requirement to introduce. Also, some text will not be able to reach 200% due to limitations due to the smaller viewport of the mobile screen

ACTION: Define "loss of content or functionality"

ACTION: Note or section about user preferences, including go beyond WCAG requirements?

ACTION: Add note about non-linear scaling (applies on Android and iOS)

ACTION: Provide guidance about determining the text size in percentages

ACTION: Mention large content viewer and other alternatives when content is limited to certain bounds

<Jamie> can we vote today on keeping or not keeping WCAG2ICT notes?

<JJ> Poll: Does 1.4.4 apply directly as written, given that assistive technology is clearly defined?

<Jamie> 0

<Tim> 0

0

<pauljadam> +1 applies as written and assistive technology are defined clearly to include screen magnifiers

<RobW> Can you share a link for the wcag2ict guidance?

<GleidsonRamos> 0

<Karla> 0

<Illai> +1

<JJ> WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#applying-sc-1-4-4-resize-text-to-non-web-documents-and-software

<Tim> I agree to the statement that assistive technology are defined clearly to include screen magnifiers

<RobW> +1

JJ: WCAG2ICT made a change to the definition of AT, but the normative text is applied as written. But in fact it changes the normative text, because the definition is different

<JJ> Poll: Do we want to include Note 1 of WCAG2ICT as written?

<JJ> The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the application works with the platform

<JJ> accessibility features to meet this success criterion.

<Jamie> +1

<Illai> +1

<Tim> +1

<GleidsonRamos> +1

<Karla> +1

<pauljadam> -1 because the text "(zoom or otherwise)" is vague and confusing

<Tanya> -1 for the same reason as pauljadam mentioned

<Jamie> "actually +1 with modification "up to 200%"

<RobW> +1 (but I do have a minor issue as above)

<Jamie> take out the "at least"

<JJ> Poll: Do we want to include Note 2 of WCAG2ICT as written?

<JJ> For non-web software, there may be cases where the platform does not scale all text up to 200%. In such cases, authors are encouraged to meet user needs by scaling text to the extent supported by user settings in the platform.

<pauljadam> -1 does not seem necessary, I'd rather a note about supporting maximum text sizes

<RobW> +1

<Tanya> +1

<Tim> +1

<Karla> +1

<pauljadam> Or maybe this note needs to talk about large content viewer

<Jamie> 0; some note about scaling is needed, with definition of non-linear scaling up to 200%. Not necessarily larger than 200% for this SC

<Illai> +1

<JJ> Summary of poll results for Success Criterion 1.4.4 guidance:

<JJ> Poll: Does 1.4.4 apply directly as written, given that assistive technology is clearly defined?

<JJ> Results: 2x +1 and 5x 0 due to definition clarification

<JJ> Poll: Do we want to include Note 1 of WCAG2ICT as written?

<JJ> Results: 6x +1 and 2x -1 for mentioning "zoom"

<JJ> Poll: Do we want to include Note 2 of WCAG2ICT as written?

<JJ> Results: 5x +1, 1x 0 and 1x -1 for limited scope

JJ: summarized the poll results incl consideration