Seeking official discussion of SC 1.4.10 Reflow on native mobile apps

[mraccess77]

My initial feeling is that SC 1.4.10 reflow would be very difficult to measure on native mobile apps like iOS and Android that are not web-based. Does this SC apply to native mobile apps? If so -- without access to the code are there any suggestions for testing?

[patrickhlauke]

The spirit of 1.4.10 is that it allows reflow when the user zooms. Native apps generally don't zoom as such (though their text/layout may rearrange/reflow based on the mobile OS's - or the app's - text size/scaling settings). As such, I'd argue that this doesn't necessarily apply to native apps on mobiles/tablets (though it could be made to apply to native apps on desktop OSs, where the app window can be resized).

Worth noting that the smaller viewport dimension (in CSS/logical pixels, rather than physical pixels) of most smartphones is around 320-380 pixels (the width, when in portrait / the height, when in landscape). For older smartphones where it is 320 pixels, arguably a native app passes the test if it only requires scrolling in one direction (if at all).

[DavidMacDonald]

Sounds like something worth discussing in the context of WCAG2ICT for WCAG 2.1. I started up a document here as a discussion point.

[WayneEDick]

Hi, Perhaps we didn't state this clearly enough, although I thought the understanding did. My impression was that the user agent must provide a way zoom with reflow for the SC to apply. I thought we excluded this example. In this example SC 1.4.4 still applies (without reflow). There is a section on the difference and necessity of SC 1.4.4 for cases like this. Maybe this should be referred to the LVTF. Best Wayne

…

On Wed, Oct 10, 2018 at 9:18 AM David MacDonald ***@***.***> wrote: Sounds like something worth discussing in the context of WCAG2ICT for WCAG 2.1. I started up a document here <http://davidmacd.com/WCAG/wcag2ict-21-discussion.html> as a discussion point. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF5J-QCFBcHSj7Y2pkbUC3BSAIHqiks5ujh3bgaJpZM4XLhtB> .

[alastc]

Hi @mraccess77,

The understanding doc does cover mobile browsers, but for native apps I don't think there is the same kind of mechanism.

Without OS support for a reflow mechanism, an app-author would have to build different layouts manually, which goes beyond the intended scope of the reflow SC. In theory it could only work for devices with more than 320px to play with, e.g. allowing a tablet to show the phone-sized view.

I've created a "wcag2ict" label for this.

[mitchellevan]

@patrickhlauke wrote:

The spirit of 1.4.10 is that it allows reflow when the user zooms.

I agree with this statement when talking about desktop browsers, where browser zoom has become the best mechanism for resizing text without assistive technology. To make this statement more technology agnostic, we should instead say "...allow reflow when the user enlarges text". Mechanisms for text enlargement include browser zoom, OS font size preferences (as @patrickhlauke correctly noted for mobile native apps), or user preferences within the web site or software product (example: Change font size in Mail on Mac).

@alastc wrote:

Without OS support for a reflow mechanism, an app-author would have to build different layouts manually, which goes beyond the intended scope of the reflow SC.

I would not categorically exempt mobile apps from reflow requirements. Android and iOS do give developers robust tools for word wrap in native apps (links below). I agree it's somewhat more challenging compared with web, but the harder challenges come from app designs that didn't consider text enlargement, not from technical limitations of the platforms. I prefer @DavidMacDonald 's note in his WCAG2ICT draft update: "It is likely that for software there will be more frequent cases where two-dimensional layout are required for usage or meaning."

Examples of word wrap in native mobile apps:

• https://developer.apple.com/documentation/uikit/uilabel
• https://developer.android.com/training/constraint-layout/

[alastc]

Hi @mitchellevan,

We'd avoided the 'enlarges text' terminology because it led people to think it was about text-only resizing, and it was more about adjusting layout (due to the content-size changes) than just text sizing.

I agree that there are mechanisms for word-wrapping, but are they not covered by 1.4.4 already?
https://www.w3.org/TR/wcag2ict/#visual-audio-contrast-scale

Do the layout options that you pointed to allow for 200-400% changes in text sizing? If not, it does seem like an unrealistic requirment.

[detlevhfischer]

It is worth noting that 1.4.10 Reflow has been included as the success criteria in EN 301549, clause 11 Software, which is the likely benchmark for mobile app testing at least across Europe (including the latest draft, V3.1.1, which now also includes 4.1.3 Status messages).

I also noted in recent app testing that apps may offer reflow (of sorts) on a tablet breakpoint in that the landscape view might be different from the portrait view, but not on a smartphone.

My general line would be that due the different enlargement mechanism in mobile apps (OS level zoom, OS level text size settings), the Reflow criterion does not generally apply on mobile devices (while it is commendable to offer it where possible). It should therefore, I think, be dropped in EN 301549 clause 11, or its application be qualified in some way.

[patrickhlauke]

beyond native "mobile" apps, i'd start questioning further how some of the SCs like 1.4.10 apply to native desktop/laptop apps - e.g. are we really expecting applications (like Word, Photoshop, etc) to satisfy the requirement of working fully and completely in a reduced desktop size of 320x256 ? that sort of level of adaptation is not present in the vast majority of native software applications today.

[mraccess77]

In a separate github thread we discussed that this requirement only applies to blocks of content and not the window as a whole. That's how I read it and how it could be applied to software.

[patrickhlauke]

yeah, i think this sort of clarification needs to be much more prominently made even for web content, and then when we finally get around to the mythical "how it applies to other ICT" document

[bruce-usab]

This issue also overlaps with #4

I have opined elsewhere that it was cavalier for EN 301549 to apply 2.2 to non-web ICT before the WG got around to revisiting WCAG2ICT.

[mbgower]

I'm late to this discussion folks, but someone was referencing the issue asking if they don't have to consider Reflow on a mobile app.
Maybe I'm missing something but there is nothing in 1.4.10 that talks about a requirement to magnify. It talks about an ability to show content at a mobile size with the need to scroll horizontally. So to me, most well designed native apps are going to pass this automatically, no?
My recollection is that it was partially written the way it is to allow it to be mainly focused on desktop displays.

[mraccess77]

@mbgower I think that’s generally how people test it today. However we’re often not certain if the mobile view is actually at 320 CSS pixels.

[bruce-usab]

The AG WG does not currently have written guidance on 1.4.10 should be applied to non-web software. Which is kind of the point of this issue, and hence the title and request for official discussion.

I hate to say it, but I do not think there can be quote official unquote discussion until such time that the AG WG formally starts working on updating WCAG2ICT. I agree there is a problem, since I agree that the need for this sort of clarification is significant and time-sensitive — because EN 301 549 adopted WCAG 2.1 without addressing if any of the new SC needed particular attention when applied to non-web software.

It is old meme: Your lack of planning does not constitute my emergency. But who might we, the AG WG, ask to put it into writing that 1.4.10 is not applicable to native mobile apps?

As a reminder, here is how the U.S. Access Board handled certain SC when it came to native mobile apps and traditional desktop software:

Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.

And before anyone asks: The U.S. Access Board has no plans for updating the 508 regulation to reference 2.1. (or 2.2, or 3.0).

[patrickhlauke]

Maybe I'm missing something but there is nothing in 1.4.10 that talks about a requirement to magnify. It talks about an ability to show content at a mobile size with the need to scroll horizontally. So to me, most well designed native apps are going to pass this automatically, no?

the slight problem (one of many) of 1.4.10 is that it was set out with high zoom on desktop in mind, and "lucked out" on justifying a classic mobile viewport width. But originally this was indeed about magnifying to 400% or more. going back to the original intent, I don't think it's realistic to assume that even on a smartphone, users that require high magnification will expect to be able to change the viewport for native content on the fly, as that simply isn't possible (compared to zooming web content inside an otherwise fixed-size native browser, but then the other issue is that on mobile/tablet browsers don't do reflow per se either, with some exotic exceptions...so beyond essentially requiring mobile-friendly viewport to be set, there not much more even for web content on mobile/tablet that can be done from the author's point of view).

[patrickhlauke]

urgh, apologies, i'm probably rehashing things i said before in this old discussion. ho hum.

[aparnapasi]

Curious and hence asking, would SC. 14.10 be applicable to Desktop non-web applications? We do sometimes have desktop applications that need to meet accessibility requirements but they are not mobile apps.

…

On Wed, Sep 15, 2021 at 2:05 AM Patrick H. Lauke ***@***.***> wrote: urgh, apologies, i'm probably rehashing things i said before in this old discussion. ho hum. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMF5F23FFJF2IYXDQYLZ2MLUB6WY7ANCNFSM4FZODNAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Satya Jaya Aparna Pasi CPWA | Director, Professional Services Deque Software ***@***.*** | +91-7093400949 "Accessibility is a feature, not an option" Squash more accessibility bugs. Start your free axe DevTools Pro trial today <https://axe.deque.com/plans?utm_source=signature&utm_medium=email>.

[maryjom]

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

[maryjom]

WCAG2ICT TF discussion on application of 1.4.10 Reflow to non-web software and documents is happening in the WCAG2ICT Issue #98 where we are discussing and drafting guidance content. Join in there if you wish to weigh in. I know some of you already are.

[WayneEDick]

I have thought about this recently. The question must revolve around need. The fluent print range of most visually based readers (with full or partial sight) runs from 16px to around 64px. In that range people can view the device at a comfortable and ergonomically sound distance. If the minimum of your fluent range is near 16px you need to ask yourself, "How much of a site can be in 8px font and still remain usable." The answer to that question will inform you as to how much text needs to be 400% for people with low visual acuity. It will also inform you as to people who have a 16px critical print size, but need a screen width of 320px. Think about the controls you can operate with an 8px font. That would corresponds to dropping form 400% to 200% A few years ago the mobile first strategy helped to create sites that functioned smoothly on mobile devices and desktop / laptops and as well. Well why not 320 by 180 first. At least 1% of users need this. These are heavy users because the inability to drive stimulates this group to use online media a great deal. This group shops, uses group communications and social media and works from home. What a group to design for first. This population presents every typical problem, and they test design flexibility. Once you've solved this problem, typical problems will be covered or trivially extended. Best, Wayne Best, Wayne

…

On Thu, May 11, 2023 at 6:00 AM Mary Jo Mueller ***@***.***> wrote: WCAG2ICT TF discussion on application of 1.4.10 Reflow to non-web software and documents is happening in the WCAG2ICT Issue #98 <#98> where we are discussing and drafting guidance content. Join in there if you wish to weigh in. I know some of you already are. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6Q4FYP377PIFUVTAWOTJ3XFTPG7ANCNFSM5YDJ3RLQ> . You are receiving this because you commented.Message ID: ***@***.***>

[maryjom]

The TF has published guidance for Applying 1.4.10 Reflow to non-web documents and software in its FPWD. If you have questions or comments on this guidance, please open a new issue.