Clarity on testing 1.4.10 Reflow on mobile devices

[ferBonnin]

In iOS, a user can change the display size by going to Settings > Display & Brightness > Display Zoom; iOS only allows for 'Default' or 'Large text'. Depending on the device used, the resolution will change (e.g. on iPhone 14 pro max the larger display setting is 375x812, in iPhone Mini is 320x693 and in an iPad Pro its 649x1024).

Should a particular device be selected for testing? if yes, what happens as older devices cycle out?

Note 6: If the content technology and platform software do not support reflow, it may not be possible for non-web software to meet this success criterion, meaning the software application would then fail this success criterion.

Note 7: Certain platforms do not support adjusting viewports to an equivalent of 320 CSS pixels wide or 256 CSS pixels high. Likewise, some platforms have limitations on zooming as high as 400% for the larger measurements of 1280 CSS pixels wide or 1024 CSS pixels high. In such cases, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies.

In this case, an iPad does support reflow so note 6 wouldn't apply and per note 7 it is sufficient to implement and evaluate at the nearest possible equivalent, so an app in an iPad that is reflowing correctly on 'large' display would pass even though it doesn't reach 320x256?

[maryjom]

@ferBonnin It seems like you are asking for test techniques for this SC, though I might be misunderstanding. Providing information on how to test or what is sufficient is out of scope for WCAG2ICT. We cannot say whether one device or a particular type of device is sufficient for testing, or exactly how to test.

What the notes are trying to cover is that sometimes a device doesn't support resizing the window/viewport. Sometimes it doesn't support increasing text size as high as 400%. IMO, in those situations you simply would increase text size to as high as you can get (if any increase is supported at all) and then see if content reflows properly without losing functionality. To me, if content reflows properly at the default and increased text size (up to 400%) or to the level supported by the platform, then this would pass.

Do you think the WCAG2ICT guidance is unclear? If so, do you have any suggested changes?

[scottaohara]

It was not the intent to ask for how to test, with the original comment, but to point out that Note 7 states that certain platforms don't support adjusting viewports to 320x256 - so in this case evaluate at the nearest possible equivalent. However, a single platform (iOS) is used on multiple different devices - all of which can produce different adjusted viewports sizes, but none of which can be adjusted to 320x256 - nor may the adjusted size be anywhere close to those dimensions (re: ipad with display zoom activated), per what the actual normative text requires. At what point is the viewport size so far away from the normative requirement that even though the viewport does zoom (let's say 200%), it doesn't get anywhere close to meeting the original criterion's viewport size?

Similarly, while most iOS devices support display zoom now, depending on how old one's device is (e.g., from what I understand, iPhone X), this feature isn't available. So here we have a single platform that allows for an adjusted version of Reflow to be met, while there are also legacy versions of the same paltform where an application could "fail" due to the feature not being supported.

I realize it isn't in the scope for wcag2ict to create normative guidance on how to test, or what to test, but it does seem like suggestions or basline use cases could be provided to help people understand what these notes are deeming acceptable, or not, while maybe also acknowledging the fact that certain devices/platforms will not be able to meet these requirement (due to being legacy as merely one example).

[maryjom]

IMO, legacy versions of products that were developed prior to a particular WCAG version becoming a recommendation might not meet the criteria, and shouldn't be expected to. This is what happens as technology progresses and new requirements are developed in the meantime. 1.4.10 Reflow was a new SC in WCAG 2.1, which was a recommendation as of 5 June, 2018. iPhone X was was announced in August 2017 and subsequently discontinued on 12 September 2018. Software that was developed to work on that phone might not be able to meet the new WCAG SC on those older devices, as support wasn't there - in the hardware and/or the OS.

It isn't up to WCAG2ICT to set policy on the timing of new criteria and what can/can't be met and when. This is why it is important that regulations are developed to cover situations where there is existing technology - that may not even be released yet that weren't designed to meet the new requirements added while the product development was already under way. This is especially true of requirements that depend on hardware/firmware/OS support, as these have development cycles that are years long.

It is also out of scope for WCAG2ICT to develop use cases. That's not to say those won't be useful - they would. But that's a larger bit of guidance that is outside of our Task Force's stated scope of work.

Even if a platform doesn't zoom to 200% or allow for resizing the viewport or even having a viewport of the exact size stated in WCAG, the concept of reflowing contiguous text within whatever viewport size is supported or for whatever text size increases are supported is better than not testing and simply failing the SC. If the limitations are documented as to the capabilities of the device and OS and then the software is tested that it works and reflows text within those parameters without loss of content or functionality, it would be as accessible as possible considering those limitations.

[patrickhlauke]

Even if a platform doesn't zoom to 200% or allow for resizing the viewport or even having a viewport of the exact size stated in WCAG, the concept of reflowing contiguous text within whatever viewport size is supported or for whatever text size increases are supported is better than not testing and simply failing the SC.

but this "just test the concept, and ignore the actual hard dimensions/sizes given in the normative text" isn't done for web content on those platforms at the moment either. so i'm not sure if the suggestion here is to special-case non-web ICT here somehow, or to say well you have to simply accept that it will fail always because the whole idea of reflow is simply not available/implemented in the same way as for basic web content on a desktop browser environment, which the normative SC seemed to assume.

[scottaohara]

IMO, legacy versions of products that were developed prior to a particular WCAG version becoming a recommendation might not meet the criteria, and shouldn't be expected to

i tend to agree for non-web content. It seems like that'd be a good line in the sand to draw to help people understand / suggest where this SC would be applicable, or not. But looking through the current draft, I'm not seeing that really being called out. For example, the only mention of 'not expected' in the doc isn't related to Reflow. And the only mention of 'legacy' is from 'legacy systems' from the Reflow intent that references making a mobile website... which i understand if just copying over the WCAG Reflow intent, but what am I supposed to interpret from this? That a native application that doesn't meet reflow should create a 'mobile' web app that does? That product teams should dump the platform they're on if it doesn't support reflow and create a new app on a platform that does? That's not likely to happen in many cases (nor is it generally reasonable adivce for web products, either - creating a separate website).

As mentioned above, but seems to have been missed/ignored in lieu of commenting on the iPhone X - an iPad Pro using display zoom will zoom in the viewport to 649x1024, which is a far cry from 320x256. Do iPads fail per note 6? Or do they pass per note 7, even though the zoomed in viewport is more than double the normative Reflow viewport expectation.

I think from this thread that it would pass. But I previously read these notes as contradictory.

[mraccess77]

The issue of legacy systems is something that isn't unique to this criteria and is really something better addressed by regulators in my opinion. Why wouldn't we say the same for any 2.2 or 2.1 criteria?

[scottaohara]

Again legacy was one part of my original comment but was not meant to be the focus…

but you’re right. It’s not unique to Reflow. It actually is better discussed in full as part of #226 since that touches on legacy as well, but also as with this issue, is not just about legacy platforms.

[maryjom]

The issue of legacy systems is something that isn't unique to this criteria and is really something better addressed by regulators in my opinion. Why wouldn't we say the same for any 2.2 or 2.1 criteria?

Agree, this is nothing to do with this specific SC. But to @scottaohara's point about WCAG2ICT saying something about regulation, that is out of scope for our document and the work of this Task Force. In fact, there have been other conversations with W3C about WCAG in general, regarding guidance needed for regulators. The direction received was to steer clear of that topic, as members of the W3C do not want involvement in political aspects of uptake of WCAG in regulations. So companies will have to continue to make comment on regulatory actions concerning WCAG and not connect that to W3C work.

[ferBonnin]

But to @scottaohara's point about WCAG2ICT saying something about regulation,

I don't think that was the intent on the request for clarification. from @scottaohara original comment:

I realize it isn't in the scope for wcag2ict to create normative guidance on how to test, or what to test

The ask here is to provide further clarity to help people understand how the S.C. could apply. As we read it right now, the notes can feel contradictory, bringing back the question around iPad's as an example:

An iPad Pro using display zoom will zoom in the viewport to 649x1024, which is a far cry from 320x256. Do iPads fail per note 6? Or do they pass per note 7, even though the zoomed in viewport is more than double the normative Reflow viewport expectation.

When is the reflow display too far? if the iPad passes per Note 7, is there a concern that, as patrickhlauke said we would be

"just test[ing] the concept and ignor[ing] the dimensions given in the normative text"?

[maryjom]

Thank you for your comment, Fernanda. There are a few issues brought up in your comment:

Issue 1: Since different devices have different resolutions, should a particular device be chosen for testing? What happens when older devices cycle out? TF answer to Issue 1: The details of testing procedures such as picking a reasonable way to test, choosing what device(s) to test on, or determining what to do when that device becomes outdated is left up to the organization doing the testing. WCAG does not provide any recommendation or advice for testing Web content on mobile devices, and it is not within the scope of WCAG2ICT work to provide those details. The Mobile Accessibility Task Force is providing further guidance as they are working to update the “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile” document and techniques for meeting WCAG in mobile technologies. It may be a more appropriate avenue to obtaining such advice, if it is within their Task Force’s scope of work.

Issue 2: Different devices have different resolutions, and may not support a scrollable pane of the particular dimensions required by this Success Criterion. This may be a limitation of various mobile devices (e.g. some phones, tablet devices) where the platform or user agent doesn’t support what WCAG requires. Answer to Issue 2: This is a general issue with Success Criterion 1.4.10 Reflow - even for Web content. There are several open issues against WCAG on Reflow. The WCAG Understanding 1.4.10 Reflow guidance should provide information to cover cases where there are technology limitations. Advice should also be given in that resource to be clear about what should be done in such a situation and whether using the “nearest possible” or “to the extent it is available” even though it may not be “near” to the dimensions provided by WCAG. Having said that, it is our understanding that current versions of Android and iOS (as of May 2024) do support a 320 CSS pixel width equivalent when display scaling is applied.

There is a WCAG task force that is focused on addressing the backlog of open WCAG issues. It might be good to contribute your input to them and/or watch for their resolution to technology support limitations.

Issue 3: Notes 6 and 7 seem to conflict. Answer to Issue 3: You raise a valid point. The WCAG2ICT Task Force has developed a change to the guidance replacing Notes 6 and 7 in the Applying SC 1.4.10 Reflow to Non-Web Documents and Software section with the following Note:

NOTE 7: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

The recently opened Issue #377 overlaps with this issue, as it proposed an added paragraph to this note. All of these changes are currently in PR #378 which will be merged into the Editor's draft after the AG WG meeting on 25 June. You can read the new text in the built document for PR 378 - see Note 7 in Applying SC 1.4.10 Reflow to Non-web Documents and Software.

We hope these changes address your concern. It will likely be up to other standards outside of WCAG to determine how 1.4.10 Reflow might need to change to address platform and/or user agent technology limitations that might prevent support of this SC for non-web documents and software. If the WCAG Understanding 1.4.10 Reflow is changed to provide more guidance on what to do in that case, following that guidance could be a defensible approach.

[maryjom]

Closing this issue. The WCAG2ICT document is now in an AG WG CfC to publish that ends on 1 July. Then the document will be published for a 30-day wide review prior to being finalized.