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

[mra11yx]

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

Copying @mraccess77 and @haltersweb here.

[patrickhlauke]

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

[mra11yx]

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

[mraccess77]

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

[mra11yx]

Cool. Thanks again @patrickhlauke @mraccess77 !

[carrythebanner]

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

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

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

[mraccess77]

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

[mbgower]

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

[jha11y]

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

[jha11y]

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

[carrythebanner]

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

[jha11y]

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

[jha11y]

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

[mbgower]

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

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

[patrickhlauke]

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

[goodwitch]

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

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

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

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

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

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

[goodwitch]

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

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

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

[peterkorn]

Glenda,

The smaller physical space of most mobile devices can make 200% text growth without horizontal scrolling very challenging. Also, if I’m not mistaken, some of the history of the 200% number connects back to the typical viewing distance and typical text size of desktop displays – which doesn’t take into account what the original size actually is (perhaps it is already big enough?) and the relative ease with which to bring a mobile device display quite a bit closer to one’s eyes. Nor does it take into account whether some of the “chrome” information on a mobile display can be retrieved in other ways where those other ways can and are rendered substantially larger (e.g. the time in the center top of the screen images below, which are rendered FAR larger than 200% by bringing up the clock app).

Regards,

Peter

Peter Korn | Director, Accessibility | Amazon Lab126 pkorn@amazon.com

From: Glenda Sims notifications@github.com Reply-To: w3c/wcag reply@reply.github.com Date: Tuesday, June 23, 2020 at 2:53 PM To: w3c/wcag wcag@noreply.github.com Cc: Subscribed subscribed@noreply.github.com 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 GitHubhttps://github.com/w3c/wcag2ict/issues/4, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA4HEQJ5QDHQF4JA2RHWGXDRYEPZZANCNFSM4HBSKERA.

[goodwitch]

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

[mraccess77]

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

[carrythebanner]

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

[jha11y]

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

[alastc]

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

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

[jha11y]

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

[goodwitch]

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

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

[alastc]

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

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

[goodwitch]

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

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

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

[jha11y]

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

[chriscm2006]

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

• 1.4.4 applied to Mobile
• Common Sense Design

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

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

[JAWS-test]

In https://github.com/w3c/wcag/issues/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!

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

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

[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 glenda.sims@deque.com, 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 notifications@github.com 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 https://github.com/w3c/wcag2ict/issues/4, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6S4WSLJUM7R6BJRRLOIUTRZHXXJANCNFSM4HBSKERA .

[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 pkorn@amazon.com

From: Glenda Sims notifications@github.com Reply-To: w3c/wcag reply@reply.github.com Date: Tuesday, June 30, 2020 at 7:38 AM To: w3c/wcag wcag@noreply.github.com Cc: "Korn, Peter" pkorn@lab126.com, Mention mention@noreply.github.com 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 glenda.sims@deque.com, 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 notifications@github.com 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 https://github.com/w3c/wcag2ict/issues/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 GitHubhttps://github.com/w3c/wcag2ict/issues/4, or unsubscribehttps://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 glenda.sims@deque.com, 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 notifications@github.com 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 https://github.com/w3c/wcag2ict/issues/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.