Wcag: 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 [e-mail]
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
https://github.com/w3c/wcag/issues/507#issuecomment-428636291, 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 https://github.com/w3c/wcag/issues/674

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.