Looking for guidance regarding SC 1.4.4, Resize Text, on mobile native apps

[mra11yx]

I've been trying to find guidance on SC 1.4.4 (Resize Text) and native apps on iOS and Android.
Both Android OS and iOS support font scaling and display scaling to various degrees. iOS calls the display scaling feature "Display Zoom"; Android calls it "Display Size." (Of note -- I'm not referring to magnification functionality. Also, the display zoom functionality, from what I've seen, is not specifically advertised within the OS as being geared toward a specific group of users with disabilities. Both platforms allow access to it from the general Display settings pane.)
When testing against SC 1.4.4 for native apps, should the display size/zoom feature be taken into consideration? For example, if an app's text can only be resized up to 170% using the OS's font resize setting (let's say the app does not support the OS's largest font sizes, like "huge" and "enormous"), but 200% can be reached by also enabling the display zoom/size feature, would this be a failure?

Copying @mraccess77 and @haltersweb here.

[patrickhlauke]

Interpretation of this will likely vary. For my own part, I've been slightly lenient in my assessments of 1.4.4 against native apps on mobile, checking primarily that it does react to the OS' text/zoom settings, but not checking if it indeed goes all the way to 200% - but noting if only "important content" parts of the app adapt (as is the case sometimes even in Apple's/Google's own default apps), if there are parts that don't adapt / subjectively don't scale enough, etc.

[mra11yx]

Thanks @patrickhlauke! For what it's worth: From what I've been able to gather (i.e., from taking screenshots on two different devices, and measuring the horizontal and vertical sizing of letters on at different sizes on each one), it's possible to scale text to 200%, but you have to set the absolute largest font size (at least on Android). And like you said, in some cases even the default apps don't scale. Samsung's (Android 8) settings app respects all font sizes, for instance, but LG's (Android 7) doesn't.

[mraccess77]

Some buttons like tab bar buttons likely can't scale past a certain amount without pushing some of the buttons off-screen and requiring horizontal scrolling. So from a practical standpoint I agree with @patrickhlauke. Some large headings might be too big if they enlarged to 200%. Areas that can wrap I would generally expect them to wrap with the maximum setting of text size. However, even Apple's own apps truncate text in table views like settings. As an iOS user it has been my experience that not all content scales the same with the dynamic text setting and Apple has changed and broken the large text functionality slightly over versions as well.

[mra11yx]

Cool. Thanks again @patrickhlauke @mraccess77 !

[carrythebanner]

Since different text styles don't scale equally, I've been using the setting which is closest to 200% for body text. On iOS, that's "AX2" — i.e. turn up text size all the way, enable "Larger Accessibility Sizes," then turn it up 2 more notches.

According to Apple's documentation, body text is 17 pt at the Default setting and 33 pt at AX2. That's 195% larger, which is reasonably close to 200%.

On Android, I've been turning up both Font Size and Display Size to their "Largest" settings. This scales primary content about 150–167%. I haven't found any options which can zoom a full 200% on stock Android. I've mostly tested with Google-produced Pixel devices, but this may vary by device maker.

[mraccess77]

Here is the Apple page that lists the sizes as the different font size levels https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography/

[mbgower]

@mraccess77 on a relevant tangent, can you or anyone else in the thread comment on the appropriateness of the technique suggested here for mobile web support for dynamic text?

[jha11y]

@mbgower the recommendation comes directly from Apple https://developer.apple.com/videos/play/wwdc2017/245/. (See page 48 of the PDF of their slides: https://devstreaming-cdn.apple.com/videos/wwdc/2017/245ti8oovkx1hl5005/245/245_building_apps_with_dynamic_type.pdf?dl=1)

[jha11y]

Also iOS "Display Zoom" is not available in iOS v12.0 and above (check on iPhone X and iPad mini 4 running iOS 12.1.4)

[carrythebanner]

Display Zoom is still available in iOS 12 on some devices, such as iPhone 6/7/8 and 6/7/8 Plus. For whatever reason, it's always been limited to certain devices.

[jha11y]

@carrythebanner interesting. I had a coworker check on and iPhone SE with iOS 12 and it wasn't available. so it seems to be a very specific set of devices. Got to love Apple's choices

[jha11y]

@carrythebanner interesting. I had a coworker check on and iPhone SE with iOS 12 and it wasn't available. so it seems to be a very specific set of devices. Got to love Apple's choices. https://support.apple.com/guide/iphone/magnify-the-screen-iphd6804774e/ios official support: iPhone Xs Max, iPhone Xr, iPhone 8 Plus, iPhone8, iPhone 7 Plus, iPhone 7, iPhone 6s Plus, iPhone 6s, iPhone 6 Plus & iPhone 6

[mbgower]

let's say the app does not support the OS's largest font sizes, like "huge" and "enormous")

So, with this information on dynamic type added into the conversation, is the iOS "larger Accessibility Sizes" considered "assistive technology" as per 1.4.4 Resize Text (and so discounted), or could one argue that if I author a site (or app) to fully allow dynamic type resizing, I have met 1.4.4?

[patrickhlauke]

I would argue that allowing any kind of resizing based on the OS sizing options passes 1.4.4. To me, it's conceptually akin to situations where a browser would not allow a full 200% resize...we wouldn't blame the author for that limitation.

[goodwitch]

I'm getting pushback from some native mobile developers (who really care about a11y)...saying it is not reasonable to expect all text on a small mobile device screen to grow by 200%. They say that the screen real estate is so much smaller.

At first, I pushed back...thinking they weren't trying hard enough. But the more native apps I looked at...the more I realized that trying to grow all text by 200% may be counterproductive.

Here are 3 screenshots of the "Favorites" native screen on iPhone:

1. screenshot 1 at Default size
2. screenshot 2 at xxxLarge
3. screenshot 3 at AX5 (largest accessible text size available on iOS)

Note that the content in the "main" part of the screen did dynamically respond to the xxxLarge and Ax5 dynamic text size. But the content in the "header" ("+", "Edit") and "footer" ("Favorites", "Recents", "Contacts", "Keypad", "Voicemail") didn't change size.

For WCAG SC 1.4.4 Resize text, does this "Favorites" screen pass (because the text content in the "main" grew? Or does it fail because the text content in the "header" and the "footer" remained the same size?

[goodwitch]

Oh, and get this, even at AX5 on iOS...the "Large Title" style has only grown 176.47% from the default.

• ios Text Size Name: Large (Default)
  • Style: Large Title
  • Size (points) 34
• ioS Text Size Name: AX5 (largest dynamic text size available)
  • Style: Large Title
  • Size (points): 60

See my detailed percentage of default text size in this google sheet: https://docs.google.com/spreadsheets/d/1lObct7JRqzEDhRgeQ7EhZ8yhpm5Vx9VXQW7bArlj9AU/edit?usp=sharing

[peterkorn]

Glenda, The smaller physical space of most mobile devices can make 200% text growth without horizontal scrolling very challenging. Also, if I’m not mistaken, some of the history of the 200% number connects back to the typical viewing distance and typical text size of desktop displays – which doesn’t take into account what the original size actually is (perhaps it is already big enough?) and the relative ease with which to bring a mobile device display quite a bit closer to one’s eyes. Nor does it take into account whether some of the “chrome” information on a mobile display can be retrieved in other ways where those other ways can and are rendered substantially larger (e.g. the time in the center top of the screen images below, which are rendered FAR larger than 200% by bringing up the clock app). Regards, Peter -- Peter Korn | Director, Accessibility | Amazon Lab126 [email protected] From: Glenda Sims <[email protected]> Reply-To: w3c/wcag <[email protected]> Date: Tuesday, June 23, 2020 at 2:53 PM To: w3c/wcag <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3c/wcag] Looking for guidance regarding SC 1.4.4, Resize Text, on mobile native apps (#674) I'm getting pushback from some native mobile developers (who really care about a11y)...saying it is not reasonable to expect all text on a small mobile device screen to grow by 200%. They say that the screen real estate is so much smaller. At first, I pushed back...thinking they weren't trying hard enough. But the more native apps I looked at...the more I realized that trying to grow all text by 200% may be counterproductive. Here are 3 screenshots of the "Favorites" native screen on iPhone: 1. screenshot 1 at Default size 2. screenshot 2 at xxxLarge 3. screenshot 3 at AX5 (largest accessible text size available on iOS) [NativeMobile1 4 4]<https://user-images.githubusercontent.com/8203866/85468236-cdfc0900-b571-11ea-9db8-50f5fe6f2d20.jpg> Note that the content in the "main" part of the screen did dynamically respond to the xxxLarge and Ax5 dynamic text size. But the content in the "header" ("+", "Edit") and "footer" ("Favorites", "Recents", "Contacts", "Keypad", "Voicemail") didn't change size. For WCAG SC 1.4.4 Resize text, does this "Favorites" screen pass (because the text content in the "main" grew? Or does it fail because the text content in the "header" and the "footer" remained the same size? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#4>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4HEQJ5QDHQF4JA2RHWGXDRYEPZZANCNFSM4HBSKERA>.

[goodwitch]

@peterkorn that is exactly what I think too. Which means...I want @alastc and company to add an exception to 1.4.4 ('cause I don't think it is reasonable to apply 200% across the board to native mobile).

[mraccess77]

Apple provides some guidance on their site concerning how the font changes with each setting https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography/ So 200% can be reached without using the largest setting. However, as you point out 200% of the heading text is likely not helpful - but not increasing the size at all on the title is likely a problem for a low vision user. So in short, text that can reflow should reflow and be 200%. Other text should enlarge depending on circumstances -- often we find that about 150% is possible in many situations -- but there are many factors as some iPhones also have a zoomed view mode (up to iPhone 8 and SE 2020) and text can also be bolded, etc. Truncation may not be helpful -- this technique is used in Apple's own apps when the text gets too large. I'd actually prefer the text to grow as much as possible up to the point of truncation (personally). Horizontal tabs often don't enlarge at all although a horizontal equivalent could be used and would also help people achieve support for different orientations as well.

[carrythebanner]

Would an exception that's similar to SC 1.4.11 be useful? For that one, the author is responsible for contrast on non-text elements except "where the appearance of the component is determined by the user agent and not modified by the author." If an author used Apple's pre-determined text types as intended by Apple, that could count as "determined by the user agent." Similar to the contrast SC, it doesn't mean that the defaults actually meet the substance of the guideline, but it does mean that you haven't subverted anything about the defaults.

[jha11y]

@goodwitch . Apple supports Large Content View for the "Header" & "Footer" and as of iOS 13 for custom elements (read: all other elements) https://developer.apple.com/videos/play/wwdc2019/261/

[alastc]

Which means...I want @alastc and company to add an exception to 1.4.4

I think we'd need to update WCAG2ICT for that, we can't put exceptions into WCAG for non-web tech.

[jha11y]

I think developers should support text resize up to the maximum allowable by the OS even if that is not 200%. This allows users to use it at the size they want. We may think the larger text sizes are not useful, but IMO unless there is empirical evidence (unbiased research) that this is not useful to users it should be supported as well as it can be and let the user who made that choice deal with the "hard to use" content.

[goodwitch]

@alastc WCAG2ICT is awfully old. I worry if we have to rely on that...that too much time will go by before this gets documented in a place where native mobile developers would even know to look.

What about adding a sufficient technique for Native Mobile to 1.4.4 (so it can easily be found from WCAG 2.1 or WCAG 2.0?

[alastc]

@goodwitch I agree with the intent, but we aren't chartered for anything that applies directly to native. There is some scope for tackling that issue under Silver, but even then we have hoops to jump through, and it will be a while.

WCAG2ICT is rather old, but with a few volunteers willing to work on it, that is something we could progress. I believe it was referenced (or at least used) by the US & EU when deciding what to apply to native mobile apps.

[goodwitch]

Alastair, what about updating these two things? They seem much more recent:

• https://www.w3.org/WAI/GL/mobile-a11y-tf/MobileTechniques/
• https://www.w3.org/TR/mobile-accessibility-mapping/

It would be ideal if the update could also include relevant WCAG 2.1 A and AA SC for native mobile.

[jha11y]

@alastc what is the timeline for WCAG 2.2? I (if there are others) would be willing to work on a WCAG2ICT or https://www.w3.org/TR/mobile-accessibility-mapping/ for WCAG 2.1/2.2 depending on how far off WCAG 2.2 is. I have lots of clients asking how WCAG 2.1 maps to native mobile. I would also want this work to help or move toward how mobile apps figure in to silver. Hopefully what I am saying makes sense.

[chriscm2006]

@goodwitch couldn't agree more with the comment that started this conversation. Sometimes Success Criteria feel mutually exclusive with each other. Adhering to one means maybe not adhering to another as completely. This is the nature of a usability driven field. The following are mutually exclusive:

• 1.4.4 applied to Mobile
• Common Sense Design

If the Working Group wants Native Mobile Content Creators to take WCAG seriously an exception would be the only thing worth adding. It shouldn't take a deep understanding of WCAG and Mobile Design research for WCAG to NOT lead you astray. Anything besides an exception is lipstick on a pig. At least in this Native iOS/Android Developer's humble opinion.

I'm super glad we're having this discussion.

[mra11yx]

Hi all, any updates/news on this?

[alastc]

@mra11yx The current situation is that:

• There isn't going to be an update to WCAG 2.x on this topic (given it's scope for web).
• Work is starting on a WCAG2ICT update, which will probably pick up steam once 2.2 is published.
• This issue will be considered & incorporated into WCAG 3.0.

So there's not immediate update, but depending on why you are asking there is plenty of advice in the thread above. Anchoring to 200% of the standard body text is a likely approach.

[maryjom]

Moved to WCAG2ICT repository as the new TF will work to address issues tagged as WCAG2ICT from the WCAG repository.

[RadhikaTakyar]

Would like to follow this thread for any more updates on 1.4.4 for transactional Native Apps.

[maryjom]

Interpreting 1.4.4 Resize Text more broadly to non-web software and native mobile applications, it seems to be a reasonable approach that text be able to expand to 200% of the application's body text size. If a particular hardware platform and operating system do not support text resizing to be fully 200% the size, it also seems reasonable that the nearest supported increase of text size should be acceptable so that application authors are not required to fix the lack of support of increasing text size by the OS. IMO, the TF should explore the potential for a note (or two) to say this, as we've taken a similar approach in Note 7 in the Applying 1.4.10 Reflow to Non-web Documents and Software.

Something to note. WCAG2ICT is not at liberty to modify any of the normative aspects of WCAG success criteria's language. I keep seeing comments to the effect that WCAG2ICT will solve various problems of applying WCAG SC to non-web, but it cannot do so if it requires a normative change in WCAG to address the issue or make the requirement clearer. We can only change the WCAG language to replace web terminology with non-web terminology. We can also add notes to indicate thoughts on application that aligns with the WCAG intent for the SC.

[chaals]

I think @peterkorn's approach is indeed the right one, but I would base it on "the smallest text size" rather than, or as well as, "body text".

"body text" is a pretty vague term in reality. It may make sense to include it alongside "smallest text used" to

1. ensure it is reasonably clear to people trying to do the right thing in normal circumstances, and
2. avoid enabling the legalistic approach of having 3 lines of small print half the size of body text that scale 200%, and then make body text scale only to 125%.

[mbgower]

"body text" is a pretty vague term in reality.

Body text is an established domain description for the default level text, and seems to me the most appropriate term to use when discussing the text most essential for the intent of Resize Text. A definition can always be generated, but I don't see why we'd abandon a typographic term established over centuries.

"Body" text is preferable to focusing on the "smallest text used", which (where a smaller text exists) is going to be used for less important text than the default size on the page. Certainly smaller text should increase, but I think the approach is more likely to specify what text is excepted, and under what conditions or formula.

Body text is also the term used in a good chunk of the industry. It is endemic, for example, in Apple's typography guidance.

[bruce-usab]

@mitchellevan offer to draft a response.

[maryjom]

The WCAG2ICT Task Force read through the long thread of comments and gleaned a few topics or points made in this issue which are listed below with our Task Force response.

Point 1: SC 1.4.4 Resize Text should require scaling in native apps to the extent supported by user settings of the platform.
TF Answer to Point 1: Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. (Examples are given of what this minimum text size could be in Section 508, clause 402.4 or ADA 2010 standard, clause 707.7.2.)

Point 2: We should allow most or all text to enlarge to less than 200%, especially when the text is initially not particularly small
TF Answer to Point 2: We've heard from the community, including members of the Low Vision Task Force, that in some contexts it can be better for users to enlarge already-large text to less than 200% of its starting size. For example, current guidance from both Google and Apple for app designers advises that as user settings double the size of body text in apps, heading text be increased to a size larger than body text but less than doubled. Such an approach would not meet SC 1.4.4, which is clear in its requirement that text can be resized to 200%. Policies outside of WCAG may allow meeting user needs in ways that do not meet the technical standards, e.g. through "equivalent facilitation".

Point 3: We've long held that PC magnifier programs are assistive technology and therefore not a method of meeting 1.4.4. Is the same true on other platforms?
TF Answer to Point 3: For Non-Web Documents and Software, features including software provided by the platform that provide a means of enlarging the text 200% (zoom or otherwise) without the loss of content or functionality, meet the intent of this success criteria.

Platform accessibility features, including platform software that, when applied, causes loss of content, including a reduction in the ability to distinguish characters, would not meet this success criteria.

[maryjom]

Closing as answered. See also the current guidance on Applying SC 1.4.4 Resize Text to Non-web Documents and Software.