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.

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.

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.

Cool. Thanks again @patrickhlauke @mraccess77 !

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.

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/

@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?

@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)

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)

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.

@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

@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

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?

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.

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?

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 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).

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.

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.

@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/

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.

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.

@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?

@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.

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.

@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.

@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.

@peterkorn EN 301549 takes a similar approach for closed functionality software:
Where any functionality of ICT is closed to the text enlargement features of platform or assistive technology, the ICT shall provide a mode of operation where the text and images of text necessary for all functionality is displayed in such a way that a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.
The subtended angle, in degrees, may be calculated from:
Ψ = (180 x H) / (π x D)
Where:
• ψ is the subtended angle in degrees
• H is the height of the text
• D is the viewing distance
• D and H are expressed in the same units
NOTE 1: The intent is to provide a mode of operation where text is large enough to be used by most users with low vision.
NOTE 2: Table 5.1 and Figure 1 illustrate the relationship between the maximum viewing distance and minimum character height at the specified minimum subtended angle.

Table 5.1: Relationship between maximum design viewing distance and minimum character height at the limit of subtended angle

Minimum subtended angle 0,7 degrees |
Maximum design viewing distance | Minimum character height
-- | -- | --
100 mm | 1,2 mm
200 mm | 2,4 mm
250 mm | 3,1 mm
300 mm | 3,7 mm
350 mm | 4,3 mm
400 mm | 4,9 mm
450 mm | 5,5 mm
500 mm | 6,1 mm
550 mm | 6,7 mm
600 mm | 7,3 mm

What is find confusing those is this appears to say the minimum height of text only needs to be 1/4 of an inch high for a viewing distance of 27 inches. That surely can't be right for people with low vision. ADA requirements are 3/16 of an inch.

@chriscm2006 a blanket exception would completely ignore the user-need in favour of developer ease. I'd rather people at least have a conversation about it and find a compromise, rather than just say "don't worry about that one".

I'm happy to organize & help with an update to WCAG2ICT (it is needed), but it needs to maintain a reasonable requirement. Whether it is based on physical size, or the platform standard, or something else.

Just looking for a couple more volunteers to make it feasible.

@alastc it's difficult for me to respond to this. It is so clear to me that the conversation you're hoping to force is so so damaging. I feel like our points of view are very very far apart on this issue. I've tried a couple times to write a longer comment that helps unify our points of view... GitHub comments is a poor place to come in line on issues where the knowledge gap is so wide.

@chriscm2006 I don't think the gap is as wide as you think. I don't do native development, but I regularly work with native app developers.

In one of the comments you deleted (note everyone on the thread gets the emails), you had a hypothetical conversation where developers had followed the platform guidelines and then were held strictly to web-guidelines, a negative outcome.

My experience working with random teams is typically:

• Developers have not followed the platform guidelines, and either not used dynamic text (iOS) or not tested text-adjustments (Android).
• We reference 1.4.4 and take a best-efforts approach, rather than strict must be 200% approach.

On iOS, if they haven't considered it before it's a big issue to make the changes, and we recommend doing that as part of a re-design in future (a bit like going from a static layout to responsive). On Android it is usually more straightforward.

That's what I mean by not having a blanket get-out clause, the user-need is met as best it can be rather than ignored.

If you've "written theses" about this topic, please do point me to them and perhaps I can understand more.

Given that WCAG is not intended to cover native apps, we can't add an exception to one SC for native apps. However, if we have a basis for meeting the user-need in a testable way, it is something that could be added to WCAG2ICT. Developers might not look at that, but regulators do.

@alastc thanks so much for your patience on this. I want to take a moment and emphasize how much I value you and all the other experts in this conversation.

I get that WCAG can't add an exception for Native Mobile Apps in normative (I'm sad...but I get it).

I'm continuing to research this because I'm looking for better solutions (I'm thinking Silver). Here is what I want (and I bet what we really all want):

People with low vision (between 20/70 and 2/0200) to be able to use dynamic text sizing to reasonably increase small text so they can see it, without losing the visual hierarchy of "heading sizes". I suspect that 200% is too blunt (ht pkorn) an instrument for all text (especially on small screens).

I'm reaching out to researchers at Smith-Kettlewell to get input from scientists who understand all the nuances of low vision, font size, viewing distance. I'll report back what I discover.

And I deeply wish I could volunteer to work on WCAG2ICT...but I'm so overdrawn on my time commitments it isn't even funny.

Thanks @goodwitch, and if you report back, that would be contributing!

Given the wide gamut of different visual impairments, it might be good to present a few practical examples for them to comment on. E.g. for a typical interface, would it be better to:

• Enable text-sizing to 200% on all text, but understand that lots of text will be cut off.
• Enable text-sizing to 200% on all text, but developers can mark some text as having an upper-limit of 130% of the OS body-text size.
• Enable text-sizing for all text up to 200% of the OS body-text size, but understand that some text will be cut off and size differentiation may be lost.
• Enable text-sizing for text up to 200% of the OS body-text size, but developers can mark some text as having an upper-limit of 130% of the OS body-text size.

That probably isn't exactly the best set of specifics, but I'm just trying to get to trade-offs between increasing size and loosing information in some way.

@alastc What about:

• Enable text-sizing up to 200% on body text
• Ensure all other text is at least as large as the resultant body text, with relative sizes to that body text and each other such that heading relationships that using relative sizes remain clear

Peter

@peterkorn I very much like where you are going with that previous comment. But I think it would need an exception for header/footer navigation (see screenshot above where the ["+" and "Edit" in the top nav] and the ["Favorites", "Recents", "Contacts", "Keypad", and "Voicemail" in the bottom nav] never resize.

@goodwitch the thing is they do resize! Turn on large text to the 1st large setting beyond the typical large setting. Go into the phone app and hold your finger down on the tabbar item - they appear in large print in the middle of the screen on the iPhone.

And without that setting I can't really see or read the icons - but there are mitigating things such as the active tabbar has a title in very large print at the top of the iOS screen!

And just because it's done this way doesn't mean the tabbar couldn't be done a different way where it becomes a hamburger menu - what would stop a developer from implementing that? They already need to change their app to meet the orientation requirement and a hamburger type menu would be needed for that.

"While they were saying among themselves it cannot be done, it was done."
Helen Keller

@mraccess77 I know! I love, love, love this new feature. But as far as I know, it is only on iOS (and only works when you have text size set to AX1 thru AX5. So, while this is a cool solution on iOS. What do we do with Android?

I don't think there is anything stopping developers from doing something similar on Android -- just because Google hasn't done it first or created an API for something doesn't mean it can't or shouldn't be done. I've run into many WCAG issues in standard Android apps. I've also have a Fire Tablet and found that it supports text enlargement in many areas way larger than Android does.

Hi all, any updates/news on this?

@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.

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

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

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.

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%.

"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.