Interpreting 1.4.4 Text Size for Mobile Apps
Resize Text is a difficult Success Criteria to translate in a mobile environment. The normative wording doesn't make fundamental design sense in a Mobile Context.
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
The problem is that the Success Criteria text is worded with the typical % Scaling Factor that exists in web browsers. This system is foundational to the way the web ecosystem works and requiring it's support on Web (WCAG) makes sense. But, not on mobile.
This article will frequently reference the WCAG 1.4.4 - Understanding article. Read it before hand if you wish, but the excerpts required for the logic of the article are quoted.
Does 1.4.4 Resize Text apply to mobile?
Of course. It is absolutely essential. Every user who sets up their device is encouraged to pick their preferred content size settings. On both iOS and Android this is a foundational feature that is configured in both the Main Settings menu and the Accessibility Settings menu.
Unless you're ready to put a ton of research and effort into rolling an Operating System integrated custom option you are best off just using the default platform font scaling recommendations. They will encourage positive limitations on the number of font styles you can choose from and support engineering practices that make development processes more efficient.
In order to do that we have to isolate the portions of the Success Criteria that make sense in a mobile platform. To do this we will investigate the corresponding understanding document!
What Doesn't Make Sense
Think about what 200 percent scaling would to to the title area of a mobile app. It would take up an absurd amount of height for the sake of displaying a title that would need truncated if it were longer than a word or two. This doesn't fundamentally make sense and conflicts with the intent of this Success Criteria.
The author's responsibility is to create ... content that does not prevent the user agent from scaling the content effectively.
To summarize the browser is a user agent. User agents should provide support for a font scaling mechanism. The author should support that mechanism.
And this is where the normative text breaks down. Apple has a system to support text scaling. Android has a system to support text scaling. Neither of them comply with the normative WCAG 1.4.4 Success Criteria wording.
So where do we go from here?
What Does Make Sense
The W3C wisely built the solution to this conundrum later on in the understanding document. Satisfy the intent of the Success Criteria, giving the appropriate exceptions that make sense and have been researched by the maintainers of the platform.
For 1.4.4 Resize Text the expectation should be that you support the existing platform mechanism for font scaling, including the recommended font scaling factors per font style, even when they conflict with the 200% mark set by WCAG.
So, this means the appropriate solution for both iOS and Android is to support the platform mechanisms for font scaling and giving consideration to the platform for the sizes of various font styles (EX: Body, Headline). This allows users a consistent experience across all of their applications. A user should not be forced to re-visit their font size settings between applications because one designer thinks Medium Body Font should be 16 and another thinks it should be 12.
Let's take a look at the iOS variation of this as it fits nicely into a table that I think I know how to make accessible in HTML... I hope :).
| Category | xS | S | M | L | xL | xxL | xxxL |
|---|---|---|---|---|---|---|---|
| Large Title | 31 | +1 | +1 | +1 | +2 | +2 | +2 |
| Title 1 | 25 | +1 | +1 | +1 | +2 | +2 | +2 |
| Title 2 | 19 | +1 | +1 | +1 | +2 | +2 | +2 |
| Title 3 | 17 | +1 | +1 | +1 | +2 | +2 | +2 |
| Headline | 14 | +1 | +1 | +1 | +2 | +2 | +2 |
| Body | 14 | +1 | +1 | +1 | +2 | +2 | +2 |
| Callout | 13 | +1 | +1 | +1 | +2 | +2 | +2 |
| Subhead | 12 | +1 | +1 | +2 | +2 | +2 | +2 |
| Footnote | 12 | +0 | +0 | +2 | +2 | +2 | +2 |
| Caption 1 | 11 | +0 | +0 | +0 | +2 | +2 | +2 |
| Caption 2 | 11 | +0 | +0 | +0 | +2 | +2 | +2 |
The iOS Font Scaling system doesn't work the same way the web ecosystem does. Notice how fonts grow at different rates by category. Also, how proportionally our larger fonts do not grow as much, certainly not the WCAG required 200%, not even close! Android has a similarly simple system. While the font size at each category does not line up with iOS, the motivations behind their choices for their users are backed by research that has clearly come to similar conclusions!
It is support for these systems, without things like screen magnifiers and the need for accessibility sizes. That is what supporting this Success Criteria looks like for Mobile Platforms.
Conclusion
Supporting dynamic font sizing is a daunting task for design teams. You can make this task much easier for yourself by supporting the mechanisms that iOS and Android provide for this.
Supporting Platform Font Scaling settings is absolutely essential for an accessible mobile application. For AA conformance supporting the base font scaling options is required. Supporting Accessibility Font Sizes would be similar to a AAA version of this requirement.
By embracing a few fundamental platform design guidelines you can design applications that scale naturally to a broad range of environments. Considering large and small font sizes early in your development process makes this a minor additional lift.