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