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

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

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

[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

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

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

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

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

[alastc]

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

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.

[peterkorn]

@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

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

[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]

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

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

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

[detlevhfischer]

Many native app developers doing public sector stuff look at WCAG because the European norm EN 301 549 reproduces a subset of WCAG in clause 11 Software — and that is the benchmark they are asked to adhere to when they try making their apps conform with the European web directive.

[goodwitch]

Hey Patrick, I had originally started this idea of an exception for native mobile. A11y experts around the world logically apply the principles of WCAG to Native Mobile. And I worry that 1.4.4 Resize Text is a tricky one for Native Mobile (fraught with the dangers of an expert calling a "failure" for something that is impossible to fix. When Alastair reminded me that WCAG is really currently limited to "web content"...I was sad...but on deeper reflection realize that I was functioning as if parts of AG/Silver were already finalized. Yes, I know that isn't true...but sometimes my future vision and the less than desirable state of current reality get blurred. I think I may have found a piece of the puzzle that I've been needing. EN 301 549 does use WCAG 2.1 A/AA for software, including Native Mobile software. And as I reread chapter 11 of EN 301 549 I saw what I needed: 11.1.4.4 Resize text 11.1.4.4.1 Resize text (open functionality) Where ICT is non-web software that provides a user interface and that supports access to *enlargement features of platform or assistive technology, it shall satisfy the WCAG 2.1 Success Criterion 1.4.4 Resize Text.* NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom. NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200 % (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement. I read this to mean that any feature on the Native Mobile operating system that allows for zooming would meet EN 301 549 11.1.4.4.4.a Resize text (open functionality)...including a setting in the "accessibility" settings. I think it would be SUPER USEFUL to document this in some way (perhaps in the Understanding for 1.4.4 and in WCAG2ICT) because if we don't...I worry that folks that are more based in web, will mistakenly think 1.4.4 Resize Text applies to Native Mobile exactly the same way it does to mobile web. G *glenda sims* <[email protected]>, cpwa <https://www.accessibilityassociation.org/certification> | team a11y lead | 512.963.3773 deque systems <http://www.deque.com> accessibility for good

…

On Tue, Jun 30, 2020 at 9:17 AM Patrick H. Lauke ***@***.***> wrote: beyond restating the definition of *Expert* (second time in this thread), can we get down to something actionable you'd like to see? WCAG itself is for web content. It currently doesn't say anything about anything being excluded. It states the principle that users should be able to resize stuff. WCAG gets reinterpreted/applied in principle to other ICT. Are you envisaging something in the WCAG2ICT document? If so, what specifically? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S4WSLJUM7R6BJRRLOIUTRZHXXJANCNFSM4HBSKERA> .

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

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

[mra11yx]

Cool. Thanks again @patrickhlauke @mraccess77 !

[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]

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.

[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]

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?

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

[JAWS-test]

In w3c/wcag#704 there is a discussion about a lower limit for the display width where SC 1.4.4 should apply. Originally, 1.4.4 was only valid for a minimum display width of 1280 px. Now it is discussed to use 640 px as minimum display width.

[alastc]

Hi @goodwitch,

what about updating [mobile techniques and mapping]?

Neither of those apply to native apps, they are still targeted at the web on mobile. Unless I've misunderstood, that wasn't the aim in this thread?

Correction (of myself): The mapping is intended to apply to mobile native, but it only really goes through how to apply various criteria (e.g. 1.4.4), it isn't a place you could provide exceptions. Whereas wcag2ict is aimed at saying whether & how criteria apply to other technologies.

@jha11y wrote:

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.

We're aiming for publication in late 2020, which means the SCs are almost settled now, barring refinements/removals based on public comments. If we get the people to work on it, it could easily start now (on WCAG 2.1 criteria) and incorporate the 2.2 criteria closer to the publication of 2.2.

@chriscm2006

If the Working Group wants Native Mobile Content Creators to take WCAG seriously an exception would be the only thing worth adding.

I really don't mean to be patronizing in pointing out that the first two words in WCAG are "Web content", but it isn't just the name. Our remit and scope is web content, not native. Whilst there are plenty of people who would rather it is otherwise (including me), if you think about it, you might work out which W3C members are adamant that it stays that way.

Also, if you are considering web content, then 1.4.4 is more achievable on web rather than native because pinch-zoom (for example) would be a mechanism to double the size.

The best avenue I can see would be to update WEB2ICT with the new criteria, and possible a mapping for particular types of ICT such as small-screen mobile devices.

[jha11y]

@alastc thankx. Sounds like WCAG2ICT could be updated to WCAG 2.1 now and add WCAG 2.2 once that work is done.

I would be willing to give some of my personal (and possibly professional) time to this effort if there is support to take it on.

Would a mapping document specifically for native mobile be warranted/allowed?

[chriscm2006]

@alastc understood and roughly agree. I've offered my services more than once on def ears :)

I must point out though... that MANY MANY development teams still attempt to apply WCAG to mobile. I've had NUMEROUS uncomfortable conversations with "WCAG Experts" about how non-sensical it is to apply this Success Criteria to Native Mobile.

Also not really patronizing... your comment is the exception I need to make these conversations MUCH easier. Though, if you're uncomfortable with me pointing this out and utilizing your comment in this way (blanket... WCAG doesn't apply to mobile... ignore that SC), maybe WE should start pushing harder :).

To me, this feels like a pretty significant step backwards.

Thank you regardless!

[mraccess77]

As a person who relies on larger text I don't understand why it's non-sensical to apply a resize text need to mobile. Users have a need for larger text on mobile and the principle can be applied on mobile and is supported by apps on mobile. In terms of the normative language there may be specific situations where exceptions are allowed - but exempting mobile apps from text enlargement is an ableist point of view. Many parts of an app can be increased in size 200% from the default - why say because it's difficult everywhere we don't need to do it at all.

Section 508 in the US does apply SC 1.4.4 to mobile and EN 301 549 does as well. So it might be worth asking regulators what type of flexibility they expect.

[alastc]

@chriscm2006 - Just to be clear, I'm speaking to our remit as a working group.

As an accessibility tester, I do use WCAG guidelines, principles and structure to test native apps, but with some flexibility (similar to Patrick's comment above). In combination with the platform guidelines, it gives good coverage for scenarios where the clients wants to make their app (more) accessible. It isn't an ideal scenario from a compliance point of view though.

@mraccess77 - I don't think anyone is suggesting to give up on it, but that a binary "does everything get to 200%" may not be feasible, as your comment above said: "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.", and some headings wouldn't be useful to get too large.

Anyway, it seems that @jha11y is volunteering to help with an WCAG2ICT update, anyone else?

[chriscm2006]

@mraccess77 because the wording of the Success Criteria is broken for Mobile and leading people to make poor design decisions. Let me take this a slightly different direction... let's define what an expert is:

1. An expert never tells you something wrong.
2. An expert leads you the correct direction A LOT.

Right now WCAG is fulfilling item 2 very well. But I've been on enough calls with enough Native Mobile Teams who've made enough TERRIBLE design decisions to know that WCAG is leading people astray on this issue.

[patrickhlauke]

WCAG is for web content, not native desktop, native tablet, native mobile. i'm really straining to see how the blame here is being placed on WCAG for how it's being reinterpreted to also apply (in spirit/principle) to cases that it was never designed to cover in the first place...

(i've already had those misgivings about making it apply to PDF, Word, etc as they're not strictly "web content")

[chriscm2006]

@patrickhlauke for one very simple reason: This is reality.

I'm not talking speculatively. I'm talking about live action developers of major corporations who are making decisions based on these documents. I have to use my deeper WCAG knowledge to talk them out of following WCAG.

These developers aren't knowledgable enough to understand that it doesn't apply. Thus an EXCEPTION is a good solution. OR more openly admitting that Native Mobile shouldn't apply generally. Though, the latter is a terrible idea!

[patrickhlauke]

@chriscm2006 where do you intend to see the clarification in the Web Content Accessibility Guidelines that the guidelines are specifically for web content and may/may not directly apply/may need to be reinterpreted for non-web content? next to each SC? in the front matter?

@detlevhfischer then it seems the EN folks would be best advised to clarify in their documentation that what they're doing is in essence taking a set of guidelines intended for web and crowbarring them to also apply in principle to non-web content...

[chriscm2006]

@patrickhlauke great question. I don't have time to join every WG call, but if you or @goodwitch point me to the correct one I'd happily provide my perspective.

My gut says that what is needed is a new standard that is edited more quickly than WCAG. That if this sub-standard existed, then we could make a strong statement somewhere that says: Stop Applying This... do this instead. A little bit like the document that already exists explaining how WCAG applies to Mobile... just more extensive and strongly worded.

My fear is that anything that is too strongly worded will limit progress that has been made in lawsuits for mobile apps recently.

This is a sticky wicket for sure... hence my advocating for a quick exception to be added for this SC.

[alastc]

I think it's understandable that regulators (or whatever the correct term is) reach for WCAG as there aren't any other independent, general digital accessibility guidelines. (Notable exception for the BBC ones, but AFAIK they aren't being updated, and they are aimed at BBC usage.)

My gut says that what is needed is a new standard that is edited more quickly than WCAG.

That's an intent for Silver / WCAG 3.0, but getting there isn't a quick process.

That if this sub-standard existed...

That would be WCAG2ICT.

My fear is that anything that is too strongly worded will limit progress

Indeed, it needs to be accurate per criterion, rather than a sweeping statement.

Anyway, it seems that @jha11y is volunteering to help with an WCAG2ICT update, anyone else?

[mraccess77]

@chriscm2006 What is this exception being discussed? If the exception is that mobile apps don't need to support text resize then I'm opposed to such an exception as resize of text in mobile apps is critical to their use by humans. Please state specifically what you propose the text resize requirements for mobile should look like?

[chriscm2006]

@mraccess77 The exception being discussed is CLEARLY outlined in this discussion... or at least clear enough from @goodwitch comments that me re-defining it would be meaningless.

Also, I'd be more than happy to see a re-write of the criteria that makes sense. My want for an exception is a balance of the following concerns:

1. Quick progress so Native Mobile Developers can take WCAG seriously.
2. Something that moves the ball forward even more.

Let me try a different approach. There's a definition of Expert I have always strongly resonated with. An Expert is:

1. Someone who never leads you astray.
2. Someone who Guides you down the correct path... a lot.

The bullet points here are very similar. After taking action regarding items numbered 1 you will have an easy time convincing me that items numbered 2 are worth addressing. We are going to have a very difficult time coming to agreement, if we don't agree that my number 1 items are valuable.

[patrickhlauke]

beyond restating the definition of Expert (second time in this thread), can we get down to something actionable you'd like to see? WCAG itself is for web content. It currently doesn't say anything about anything being excluded. It states the principle that users should be able to resize stuff. WCAG gets reinterpreted/applied in principle to other ICT. Are you envisaging something in the WCAG2ICT document? If so, what specifically?

[alastc]

For example, the entry for 1.4.4 in WCAG2ICT simply states that it applies as written.

Where as others apply different notes or terms to the SCs.

From the points in this thread, I don't think it should be a blanket exception, but I'm not sure if it would be best to define a lower threshold (e.g. 150%), or say that people should be able to get to a minimum size (e.g. 20pt/px / device independent pixels).

[peterkorn]

Glenda, colleagues, Do we have historical information on how SC 1.4.4 came to be? I recall in the Section 508 refresh meetings discussions around “typical viewing distance” for similar requirements that were being considered. I wonder if the importance of magnification amount changes depending upon the ease with which someone can comfortably move their eyes closer to the screen. Separately, something that has always bothered me about 1.1.4 is that it doesn’t take into account the original font size. Imagine I’ve written a mobile web game edition of “red-light/green-light” consists of a single button that fills the entire width of a screen with a single button and maximally sized text (to fit the screen) with either the word “red” or “green” in it. There is no room to further enlarge the text of that button – it is as wide as the screen is (in landscape mode). It would technical fail this criteria, yet be more accessible to someone with magnification needs than nearly any other app running. Clearly that doesn’t make sense. Perhaps this is something that can be addressed in WCAG 3. Peter -- Peter Korn | Director, Accessibility | Amazon Lab126 [email protected] From: Glenda Sims <[email protected]> Reply-To: w3c/wcag <[email protected]> Date: Tuesday, June 30, 2020 at 7:38 AM To: w3c/wcag <[email protected]> Cc: "Korn, Peter" <[email protected]>, Mention <[email protected]> Subject: Re: [w3c/wcag] Looking for guidance regarding SC 1.4.4, Resize Text, on mobile native apps (#674) Hey Patrick, I had originally started this idea of an exception for native mobile. A11y experts around the world logically apply the principles of WCAG to Native Mobile. And I worry that 1.4.4 Resize Text is a tricky one for Native Mobile (fraught with the dangers of an expert calling a "failure" for something that is impossible to fix. When Alastair reminded me that WCAG is really currently limited to "web content"...I was sad...but on deeper reflection realize that I was functioning as if parts of AG/Silver were already finalized. Yes, I know that isn't true...but sometimes my future vision and the less than desirable state of current reality get blurred. I think I may have found a piece of the puzzle that I've been needing. EN 301 549 does use WCAG 2.1 A/AA for software, including Native Mobile software. And as I reread chapter 11 of EN 301 549 I saw what I needed: 11.1.4.4 Resize text 11.1.4.4.1 Resize text (open functionality) Where ICT is non-web software that provides a user interface and that supports access to *enlargement features of platform or assistive technology, it shall satisfy the WCAG 2.1 Success Criterion 1.4.4 Resize Text.* NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom. NOTE 2: This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200 % (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement. I read this to mean that any feature on the Native Mobile operating system that allows for zooming would meet EN 301 549 11.1.4.4.4.a Resize text (open functionality)...including a setting in the "accessibility" settings. I think it would be SUPER USEFUL to document this in some way (perhaps in the Understanding for 1.4.4 and in WCAG2ICT) because if we don't...I worry that folks that are more based in web, will mistakenly think 1.4.4 Resize Text applies to Native Mobile exactly the same way it does to mobile web. G *glenda sims* <[email protected]>, cpwa <https://www.accessibilityassociation.org/certification> | team a11y lead | 512.963.3773 deque systems <http://www.deque.com> accessibility for good

On Tue, Jun 30, 2020 at 9:17 AM Patrick H. Lauke ***@***.***> wrote: beyond restating the definition of *Expert* (second time in this thread), can we get down to something actionable you'd like to see? WCAG itself is for web content. It currently doesn't say anything about anything being excluded. It states the principle that users should be able to resize stuff. WCAG gets reinterpreted/applied in principle to other ICT. Are you envisaging something in the WCAG2ICT document? If so, what specifically? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S4WSLJUM7R6BJRRLOIUTRZHXXJANCNFSM4HBSKERA> .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4HEQNMFQ5B4RMQLEF3JPDRZH2DLANCNFSM4HBSKERA>.

[mraccess77]

I've also read the EN 301 549 standard and it's not fully clear to me what the intent of the remarks are -- but it does seem to allow assistive technology whereas WCAG does not. It's unclear for certain if the three finger zoom feature on iOS acceptable for meeting this requirement or not? Generally, for WCAG, we have taken the stance that the Zoom feature on iOS that requires three fingers is assistive technology while the large text feature is not assistive technology. What I don't understand is why this is so much of an issue. Many apps on mobile support the large text feature or built in large text feature and the text size increases. The three finger zoom feature is very clunky and the large text feature that reflows is much better. There are many aspects of apps where the text can easily reflow and wrap.

Have you ever read a book by panning around the screen rather than by having the text reflow? I have and the impact and fatigue is tremendous. We have studies showing how reflow is better. We have 1.4.10 but it's not clear how it applies to mobile -- so in short we are discussing allowing apps to just rely on assistive technology zoom rather than supporting the large text feature.

Don't forget that the EU standards and 508 standards also require the following:

11.7 User preferences
Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

C 11.7 Inspection and Testing
1.  The software is software that provides a user interface. 2.  The software has settings for language, colour, contrast, font type, font size, or focus cursor, that correspond to platform settings. 3.  The software is not designed to be isolated from its underlying platforms.

1. Check that the software provides a mode of operation that follows the platform settings.
   Pass: Check 1 is true Fail: Check 1 is false Not applicable: Pre-condition 1, 2 or 3 is not met

[goodwitch]

Hey Jon, The reason that this is a pain point for me..is I'm doing audits on real native apps and have hit a number of situations where text is already very large in the default (for a heading and/or a button label). If we forced a 200% zoom on the native app (no scrolling, no panning)...there literally is no way to fit all the content from the default screen onto the 200% increase screen. I deeply care about the low vision user group. Heck, I am experiencing very bad vision and hold my phone to my nose all the time to read it. I think Peter's question is right on point for what I'm saying. If, in the default view, there is a heading that starts at 34 point and body text that starts at 17 point. If we force 200% zoom on the 34 point..making it 68 point. Was that really needed? I also understand the need for keeping relative sizing as you grow the body text (of 17 point to 34 point). So...I'm not talking about Native Apps that read like an online book, newspaper or magazine article. I'm talking about transactional native apps. And the 200% requirement on every piece of text (even text that has started out as huge) doesn't leave a way for a developer to solve the problem. (at first, I thought maybe the developer just needed to try harder...but the more I've looked at native mobile apps across industries...the more I'm understanding...that we just put the developers between a rock and a hard place). Again, going back to Peter's question...where did the 200% derive from? What level of low vision are we trying to solve for? And what is the expected reasonable distance of the screen? I bet that 200% was chosen for a screen that we expected to be more than a foot away from the face. Back in that day...craning your neck up closer to the screen was something that didn't make sense (and still doesn't for desktops and laptops). But mobile devices...are much easier to hold up closer to our eyes. The moment that my mind changed about this was when I calculated when Apple's accessibility large text size all hit 200% above base. You see, the Large Title default font size on Apple iOS starts at 34 point. Apple currently gives us an awesome 8 increasing size choices above default (xlarge, xxlarge, xxxlarge, AX1, AX2, AX3, AX4. AX5). And, get this, that Large Title that started at 34 point only makes it up to 60 pt (176.47% larger than default) when the large text setting is at the top..which is AX5). Here are my calculations: https://docs.google.com/spreadsheets/d/1lObct7JRqzEDhRgeQ7EhZ8yhpm5Vx9VXQW7bArlj9AU/edit#gid=0 And, may I say, Apple did a fabulous job of maintaining size differences between the font styles in each text option. In other words...you can still notice that the Title 1 is larger than Title 2 and so no. I can't show you the Native Mobile interfaces I'm dealing with...because it is NDA client work. But I bet y'all a dollar that if you were looking at what I'm looking at....you'd be concerned that we are asking native mobile developers to do something that is unreasonable. G *glenda sims* <[email protected]>, cpwa <https://www.accessibilityassociation.org/certification> | team a11y lead | 512.963.3773 deque systems <http://www.deque.com> accessibility for good

…

On Tue, Jun 30, 2020 at 10:27 AM Jonathan Avila ***@***.***> wrote: I've also read the EN 301 549 standard and it's not fully clear to me what the intent of the remarks are -- but it does seem to allow assistive technology whereas WCAG does not. It's unclear for certain if the three finger zoom feature on iOS acceptable for meeting this requirement or not? Generally, for WCAG, we have taken the stance that the Zoom feature on iOS that requires three fingers is assistive technology while the large text feature is not assistive technology. What I don't understand is why this is so much of an issue. Many apps on mobile support the large text feature or built in large text feature and the text size increases. The three finger zoom feature is very clunky and the large text feature that reflows is much better. There are many aspects of apps where the text can easily reflow and wrap. Have you ever read a book by panning around the screen rather than by having the text reflow? I have and the impact and fatigue is tremendous. We have studies showing how reflow is better. We have 1.4.10 but it's not clear how it applies to mobile -- so in short we are discussing allowing apps to just rely on assistive technology zoom rather than supporting the large text feature. Don't forget that the EU standards and 508 standards also require the following: 11.7 User preferences Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user. C 11.7 Inspection and Testing 1. The software is software that provides a user interface. 2. The software has settings for language, colour, contrast, font type, font size, or focus cursor, that correspond to platform settings. 3. The software is not designed to be isolated from its underlying platforms. 1. Check that the software provides a mode of operation that follows the platform settings. Pass: Check 1 is true Fail: Check 1 is false Not applicable: Pre-condition 1, 2 or 3 is not met — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S4WXUOACX7A3O32DD533RZH76HANCNFSM4HBSKERA> .

[mraccess77]

@goodwitch if you scroll up through the conversation you will see that I pointed out the same issue with headings and also suggested that size limitations for certain elements may be capped in a certain range of 150% or 170% as well. Even in a transaction app like a bank account individual transactions can often wrap and often do increase in size. This is why I asked in my other post for your colleague to propose something other than simply saying this SC doesn't apply to mobile and that if we don't exempt this SC then it looks like WCAG was created by students.

In terms of holding things closely - holding a phone or iPad closely is very hard unless you crane your neck. My neck is very sore and simply looking closer can actually make text blurry. Using reading glasses gives me a headache. 200% magnification of body text is not an unreasonable ask and is absolutely needed for the low vision community I would not go lower. In terms of headings and other types of content if the size is differentiated and is already 200% of the size of the default body text then an allowance could be made. Again this is what I discussed in my past posts in this thread. The tabbar solution has already been provided by Apple where you can hold the tabbar icons and see the text larger - so solutions do exist for different situations. I posted the link to the Apple fonts which show the font size increases. One option would be to determine what is doable and then user test that to determine if user needs are met and then tweak a recommendation that covers truncation, expansion options, etc. so we can figure out something that works without just saying experts never lie and saying that if this SC can't be applied all of WCAG can be thrown out. When a person says such rhetoric it is not helpful to anyone.

Keep in mind that the needs of people who have low vision is substantially different from people who may need some increased font size because of age. There are different needs on a continuum. The needs of people with low vision are in the range of people who are not legally allowed to operate a motor vehicle due to vision and without enlargement would not be able to use a mobile phone or UI. There is a substantial difference on ability to function in an environment without modification of the environment to meet their needs.

[peterkorn]

Jonathan, Why is a % increase the correct answer for native mobile apps instead of a minimum absolute size? If a given app has a small amount of body text that is already large – say 1/3” tall (24 point) or ½” tall (36 point) – and further any headers (if they exist) are sufficiently larger still that they are clearly headers, why should we still require a further 200% increase of this body text? Why isn’t the right answer to specify minimum text heights & text clarity (and perhaps also font face & rendering characteristics)? A % increase minimum is a very blunt instrument… Peter

[patrickhlauke]

@peterkorn

Why is a % increase the correct answer for native mobile apps instead of a minimum absolute size?

because, just as with web, it's mostly impossible for authors to define exactly how big, in physical size as measured on the screen itself, something renders. and if an app targets multiple devices (think android and its myriad of subtle variations on actual physical size, pixel density, intended viewing distance, etc) it becomes can become a futile request to mandate an actual hard absolute size.

and say a developer does try to define some size and test on the majority of common devices to ensure they all roughly hit at least the minimum absolute size...then some new device comes out with subtly different metrics, and the minimum size is not achieved...does that fail the requirement? is it the author's fault?

@goodwitch

If we forced a 200% zoom on the native app (no scrolling, no panning)

1.4.4 does not disallow scrolling or panning. it's not 1.4.10 reflow

[peterkorn]

Patrick, On Android, you can specify “density-independent pixels”, which should allow you to create a UI that is rendered at the same physical size, whatever the overall screen size or pixel density of the UI. See https://developer.android.com/training/multiscreen/screendensities for details. Haven’t been close enough to iOS development to recall a similar mechanism there… Regards, Peter

[patrickhlauke]

yes, i'm aware of that (and Apple's "point" measurement which is unrelated to typographical pt and the CSS pt; and Microsoft's "effective pixel"; and the old trusty CSS ideal pixel). but you can't really build a tech-agnostic SC using vendor-specific measurements.

(ed: the difference with CSS ideal pixel, which is indeed used in WCAG, is that it's vendor-neutral and part of the standard web platform which user agents should all follow)

[mraccess77]

@peterkorn I am open to methods that have the effect of creating text that is large enough for people with significant vision loss to read. The easiest way to address this across different device sizes is to use percents as the default text size for any technology will likely be the size needed for the typical viewer and thus we need a way to effectively increase that. It is true that apps and sites can use large text that is large enough and may not need to be increased - but in large part I think that is an edge case or only occurs with certain situations like headings. Saying that 36px text is big enough might be sufficient for a phone but is likely not enough for a TV where the user can't get as close or where moving too close would reduce the size of visual field significantly. I just don't want to end up in a situation where we say 14pt is big enough when on a number of devices it isn't big enough. The large print requirements in the ADA are not large enough for the average person with low vision. Assuming that designers will only make text large enough by default for the typically reader has bee pretty accurate to this point.

[alastc]

Saying that 36px text is big enough might be sufficient for a phone but is likely not enough for a TV where the user can't get as close or where moving too close would reduce the size of visual field significantly.

I think the approach would be to say something like:
"For native applications devices with a small screens such as mobile phones and watches, it can be problematic to increase all text to 200% of the default. However, as a minimum the text in an application should be able to be increased to 200% of the system default body-text size, rather than 200% of the starting point."

[chriscm2006]

@patrickhlauke sorry to be redundant. I feel like people lose track of the importance of being a good Expert in favor of politics and bullshit. It's worth brining up from time to time to remind people that are job is to Guide people to create more Accessible content. You're correct! I should be more straightforward. Here is my stance on this:

An expedient blanket exception for mobile on this is necessary. This should be followed up with a long term evaluation of the Success Criteria to re-write it so the exception can be removed.

This is the ONLY process that would leave me feeling satisfied on this issue. Or at least is the only thing that would lead to my Productive Silence on this issue.

Issues like this and them not being taken seriously are why I stopped participating actively in the evolution of WCAG. My relationship with @goodwitch is the only thing that pulled me into this particular conversation. Which I now respectfully bow out of.

My position on this is abundantly clear. I'm available for private conversations about anything accessibility related at any time. Non-productive silence resumed.

[peterkorn]

@mraccess77 Why can't we work backward from the customer need? 20/40 vision means "I need to be 20' away to read something that someone with 'normal' vision can read from 40' away". In other words, 2x (40/20) or 200%.

So let's consider this in the TV context. Googling for "typical viewing distance for a TV" turns up as a first hit guidance from BH Photo Video "A general guideline is to sit between 1.5 to 2.5 times the diagonal screen measurement away, with about a 30-degree viewing angle. For example, if you have a 40" TV, you should be sitting somewhere between 5 and 8.3 feet from the screen." For the sake of argument, let's take the lower end of that range (1.5x diagonal width), which means I should sit not closer than 5' away from a 40" TV.

If (at least a mode of) the user interface on that 40" TV is readable from 2x the "typical viewing distance" (2 x 5' = 10' in this case), then that UI might be considered to meet 1.4.4.

You can walk through the same logic for typical viewing distance of any visual UI. The monitor on a desktop computer. A phone held in the hand. A digital watch.

You can decide that 2x typical viewing distance isn't right and you want to go higher (or lower), or in a Silver context maybe you have three (or more) levels corresponding to bronze/silver/gold. But that's the idea. And it doesn't require that all UIs be resizable by at least 200%, whether that actually makes sense in a given context or not.

[mraccess77]

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

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

[alastc]

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

[goodwitch]

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

[goodwitch]

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

[mraccess77]

@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

[goodwitch]

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

[mraccess77]

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.

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

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