1.4.10 Reflow - Guidance & notes for non-web software

[maryjom]

Split #98 into smaller areas of focus. This issue is to focus on developing guidance and notes on applying SC 1.4.10 Reflow to *non-web software.

Original proposal

For non-web software:

Note 1: The intent section refers to the ability for reflow content when user agent text enlargement is used to scale content or when the viewport changes in width. For non-web software, this would mean that when those features are used, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions or that the application works with the platform features that meet this requirement.

Note 2: It is likely that for non-web software there will be more frequent cases where two-dimensional layout is required for usage or meaning. For example:

• If the platform software does not provide reflow capabilities.
• When the software has a complex user interface with toolbars, as explained in the intent of Understanding 1.4.10 Reflow.
• When the size of the viewport and the size of the content cannot be altered.

Comments on the proposal

Mitch's comment and proposal

Issues:

• Nit: "ability for reflow content" is awkward
• "when those features are used" - Passive voice makes it a bit unclear whether this means developers or users using the feature. It's not clear what a "viewport change" means for software.
• "If the platform software does not provide reflow capabilities" is incomplete. The responsibility lies in a combination of the content and the platform.
• "When the size of the viewport and the size of the content cannot be altered" - Passive voice makes it unclear whether this is talking about developers or users altering the sizes.

Proposed:

For non-web software:

Note 1: The intent section refers to the ability for content to reflow when user agent text enlargement is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this requirement.

Note 2: It is likely that for non-web software there will be more frequent cases where two-dimensional layout is required for usage or meaning. For example:

• If the content technology and platform software do not provide reflow capabilities.
• When the software has a complex user interface with toolbars, as explained in the intent of Understanding 1.4.10 Reflow.
• When the content technology and platform software do not allow users to alter the size of an application window or its content.

I'd also like to discuss how 1.4.10 applies to software on platforms that support size alteration, yet put limitations on the possible size.

• On macOS, users can resize application windows and adjust screen resolution, but I've never been able to adjust these all the way down to the 320 dip equivalent. Can we say 1.4.10 applies to the extent size alterations are available?
• Conversely: Adil Hussain at the Norwegian digitalization authority contacted me about 1.4.10. His agency is defining test procedures for mobile apps to meet Norway’s accessibility laws and is looking to WCAG2ICT as an important reference. The agency’s current draft solution is to test mobile apps for 1.4.10 Reflow down to a screen width equivalent of 360 CSS pixels only, because this is a single feasible size for both iOS and Android. I feel that they should test Android down to 320 CSS pixels. Can our WCAG2ICT update give guidance on this matter?
• Theoretically, a physically small but high resolution screen (e.g., a watch) could by default render apps narrower than 320 dips, then enable users to zoom out to a width equivalent to 320 dips. Enlarging content to evaluate 1.4.10 feels wrong, but I don't see a normative reason not to. Can our WCAG2ICT update give guidance on this scenario?

Jonathan Avila comment regarding software

I don't read the SC as requiring any software windows to be resized as the requirement is on the content itself being readable without 2 dimensional scrolling.

There is software such as pixel rules for Windows, Mac, and Android that could be used with non-web software and non-web documents - obviously for hardware it would be difficult to measure that precisely though as software isn't an option.

[mapluke]

I don't read the SC as "not requiring any software windows to be resized". WCAG defines content as:

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions

It has always been my understanding that for software, everything that appears on the screen is "content", including windows. The parts of the content definition that I have bolded above seem to be saying that to me. So, if this is correct, window resizing is surely one thing that is necessary to correctly present the content.

[maryjom]

The non-web software notes for this SC have been approved by the TF (on 6 and 13 July) and can be found in the editor's draft. The AG WG will review the 1.4.10 Reflow SC in its entirety starting 14 July and the survey will be discussed on 20 July in the AG WG meeting.