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.

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

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

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

[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

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

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