Success Criterion 1.4.4 - Resize Text - Level AA

[JJdeGroot]

Discussions:

15 April 2024

Source

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

<Joe_Humbert> 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

<Joe_Humbert> 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

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?

[jamieherrera]

A colleague reminded me of the Large Content Viewer feature on iOS (I'm not as familiar with a related feature in Android) which can be added to the API as a custom feature in places like tab bars in a native app (as of iOS 13). When the native implementation does not resize with OS size changes, users with Larger Accessibility Size on can longpress to temporarily see a larger version of a button icon or text from these spaces. This doesn't really change much from the language of the WCAG2ICT or Notes, but could be a helpful discussion to include in techniques

[JJdeGroot]

Related discussion in WCAG2ICT: w3c/wcag2ict#4

It's challenging to understand the difference between assistive technologies and accessibility features.
The usage of assistive technologies would fail ("without needing to use assistive technologies.") while accessibility features would pass ("the application works with the platform accessibility features").

Assistive technologies is defined as term and lists "screen magnifiers, and other visual reading assistants" in the examples.

So it seems that zoom functionality provided on mobile operating systems would fall in the assistive technology category and not in the platform accessibility features category.

The "three tap zoom" functionality is not mentioned explicitly, but considering that's also specifically targeting visual impairments it would probably as be categorised as assistive technology.

I think it would really help app developers if we would clearly distinguish which functionality falls in the assistive technology category, and which falls in the accessibility features category.

[doesDesign]

Thank you @JJdeGroot for bumping this one! I created an issue at w3c/wcag2ict/issues/527 because I wasn't able to tag a few W3C folks I had in mind. I agree it's very challenging especially with this new guidance in WCAG2ICT

[JJdeGroot]

Based on info from w3c/wcag2ict#527 and #67 (comment), it seems that:

• Following the normative text of WCAG2ICT, system zoom would be a way to pass 1.4.4, even if text does not scale.
• Following the normative of EN 301 549, you would not pass because you would not honor the user preferences for font size defined in Chapter 11.7

[JJdeGroot]

Some research about non-linear text scaling:

iOS

Starting from iOS 11, text is scaled using Dynamic Type. The factors are defined in Typography Specifications.

The default scale is Large

Style	Weight	Size (points)	Leading (points)
Large Title	Regular	34	41
Title 1	Regular	28	34
Title 2	Regular	22	28
Title 3	Regular	20	25
Headline	Semibold	17	22
Body	Regular	17	22
Callout	Regular	16	21
Subhead	Regular	15	20
Footnote	Regular	13	18
Caption 1	Regular	12	16
Caption 2	Regular	11	13

For body text, the default is 17 points, meaning we need to reach 34 points for 200% scaling.

At AX2 the size is 33 points, meaning we need to choose AX3 which is 40 points (235% scaling)

I've calculated the percentages for each size from Large to AX3:

Style	Weight	Size (points)	Leading (points)
Large Title	Regular	52 (153%)	61
Title 1	Regular	48 (171%)	57
Title 2	Regular	44 (200%)	52
Title 3	Regular	43 (215%)	51
Headline	Semibold	40 (235%)	48
Body	Regular	40 (235%)	48
Callout	Regular	38 (238%)	46
Subhead	Regular	36 (240%)	43
Footnote	Regular	33 (254%)	40
Caption 1	Regular	32 (267%)	39
Caption 2	Regular	29 (264%)	35

Android

Starting from Android 14, text is scaled non-linearly. The docs tell you how to convert values, but there is no table indicating which scaling factor is applied.

Luckily, Android is open-source, the FontScaleConverterFactory.java class holds the non-linear scaling values. The values are generated using font-scaling-array-generator.js

The definition:

/* fromSp= */
new float[] {   8f,   10f,   12f,   14f,   18f,   20f,   24f,   30f,  100},
/* toDp=   */
new float[] {  16f,   20f,   24f,   26f,   30f,   34f,   36f,   38f,  100})

In table form:

Base Size	Scaled Size	Scale
8	16	200%
10	20	200%
12	24	200%
14	26	186%
18	30	167%
20	34	170%
24	36	150%
30	38	127%
100	100	100%

It seems that text larger than 14 sp will never reach 200% text scaling on stock Android.

---

On Figma, you can also find visual research by Juliana Mendonca (Jules)