Success Criterion 1.4.4 - Resize Text - Level AA

[JJdeGroot]

Discussions:

15 April 2024

[Source](https://www.w3.org/2024/04/15-matf-minutes.html#t04) ## 1.4.4 Resize text JJ: question: does resize text apply? JJ: what's interesting is that OS settings can be used for this… with websites, this works differently JJ: with apps it is trickier to determine the percentage…and in iOS there is dynamic font sizing now JJ: that makes it even harder to determine how much textt even has scaled. And we cannot inspect tex QuintinB: what's completely missing… not sure how it works in iPhone but in Android, because we have scale independent sizes, we could set a minimum font size. This has been missing from WCAG since forever QuintinB: so you could say this is the smallest we allow and then go to scaling on iOS they have typography in the human interface guidelines that give the pt size for all font styles and font sizes JJ: wonder if we can add some kind of recommendation in guidelines Carolina: if we're able to scale / zoom in and out, would only one be required or both of them? Carolina: on iOS I use large, on Android I use the maximum Carolina: do we need to allow for both? joe_humbert: do you mean in hybrid situations? Carolina: I mean if you have the web view should you be able to pinch zoom and out? The Evinced MCAG reduces everything to pixel sizes, maybe that is a logical way to go I do think we need to have a "standard minimum" font size JJ: another issue is that WCAG uses CSS pixels wjhich for apps you'd ned to convert I would strongly suggest to drop the "200%" spec from a mobile interpretation; 200% or 2x is very web-based thinking particularly for larger heading font styles Karen: in the passed we said we should not disable scaling Karen: but others say now that as long as magnification works that suffices, have you discussed that here? I don't think relying on magnification because that may be seriously inconvenient for many people JJ: don't think we have discussed that here JJ: is it sufficient if an app has its own resizing mechanism? If the device supports actual text scaling through setting, apps should support that capability. agree with julianmka But at what point does it need to support the font size without loss of content or functionality? JJ: the bold font setting is also interesting, lots of users (10%) use it we found in research woah - can we get references for that? Bold text stats: https://appt.org/en/stats/bold-text I love me some sweet sweet data thanks "But at what point does it need to support the font size without loss of content or functionality?" -- show it all, let users determine whether it's functional/meets their needs Also agree with julianmka +1 julianmka making it a part of the SC JJ: in iOS / Android there is a limit too It would be interesting to know how the web folks arrived at 200% JJ: not sure if there is a limit on websites +! QuintinB Android can be done via ADB, it's just a multiplier as a float value JJ: there are all users who decrease font sizes Julian: could we include some kind of statement that when an OS supports a specific AT or accessibility setting, that app developers should support it? Mobile Device Features sheet: https://docs.google.com/spreadsheets/d/1j1-C7t4sHtJqLT4YKJqLfJIl28DET6gYBQPczDFDWpY/edit#gid=0 Julian: we often hear about users with edge cases… Joe_Humbert: should be careful about 'should' vs 'must'… eg there could be features that are newly released and developers might not have time to explore new features before they are released, could take months Julian: valid point On the other hand, you get settings that don’t get respected for months, to the point where the documentation actually says that it’s not usually respected because developers don’t know about it (e.g. android time to react) JJ: maybe we can fort certain features, like text scaling, but not others Sorry, years, not months Could state support must be given for a certain OS version, so not to put pressure around new releases Jamie: are you sharing the doc because you feel it should be updated? JJ: would be good to keep an eye on new features and discuss in these meetings how we deal with the new features JJ: in the European rules there are a lot of requirements around user preferences, like color preferences I think with Assistive technology/settings we could recommend a support timeline. Like support new AT within 1-2 years, but not sure that follows other specs/notes hdv: is it EN 301 549? I don't see Full Keyboard Access on the linked document, which is available since 1OS 14. Did I miss it? JJ: yes, 3.2.1 of that JJ: feel free to add any features that are missing

1. Interpretation and Application:

• JJ: Raised questions regarding the applicability of the resize text criterion, particularly in the context of mobile apps.
• QuintinB: Suggested implementing a minimum font size requirement as a precursor to text scaling, especially in Android.
• Joe_Humbert: Noted the typography guidelines in iOS Human Interface Guidelines, offering specific font sizes for various styles.

2. Device-specific Settings:

• Carolina: Inquired about supporting text scaling settings on both iOS and Android devices.
• julianmka: Advocated for supporting text scaling based on user preferences set in the operating system.

3. Magnification vs. Native Scaling:

• Karen: Raised the question of whether reliance on system magnification settings is sufficient for meeting the criterion.
• QuintinB: Argued against solely relying on magnification due to potential inconvenience for users.
• JJ: Explored the possibility of apps having their own resizing mechanisms in addition to system settings.

4. Accessibility Settings and Support:

• Julian: Proposed recommending app developers to support OS-specific accessibility settings, such as text scaling.
• JJ: Highlighted the importance of keeping abreast of new accessibility features and discussing their implementation in meetings.

5. Compliance and Documentation:

• Mick: Suggested setting support timelines for new accessibility features to balance developer workload and compliance.
• QuintinB: Shared experiences where certain settings were not respected for years due to developers' lack of awareness.

[jamieherrera]

1.4.4 reference to "without assistive technology" would be helpful to clarify in the documentation whether text sizing in an Accessibility section such as mobile Chrome browser, would be "assistive technology" , whether for mobile web or mobile apps.

[jamieherrera]

Would mobile web be exempt from this SC? Some of my work colleagues feel strongly that 1.4.10 for testing desktop web is sufficient to catch any content or functionality issues on small screens, and that the informative ACT rule on the viewport meta tag https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/ enables pinch to zoom by not disabling the viewport meta tag. Since type of text resize / zoom is not defined, the argument is that the ability to pinch to zoom is a sufficient test for this SC for mobile web.

[JJdeGroot]

Discussion during MATF meeting on June 12, 2024

[Source](https://www.w3.org/2024/06/12-matf-minutes.html#t01) Jamie: elaborating on comment to Github issue on 1.4.4 (audio problems) victoria: it should be a violation if there is an option to increase text size in the OS … agree that pinch to zoom satisfies 1.4.4 but it may not wor for all... Detlev: explaining German ways of testing 1.4.4 EN 301 549 criterion 11.7 "User preferences": https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf#page=82 Detlev explains line of though linking 1.4.4 ans 11.7 (EN 301 549)

[jamieherrera]

note updated text in WCAG2ICT draft https://w3c.github.io/wcag2ict/#resize-text - should we be discussing/ including terms like Closed Functionality from WCAG2ICT in our Mobile supporting doc?