Success Criterion 1.4.10: Reflow (Level AA)

[maryjom]

From Success Criterion 1.4.10:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

NOTE: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

NOTE: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

Additional Guidance When Applying Success Criterion 1.4.10 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.10 (also provided below), replacing “web content” with “content”.

With these substitutions, it would read:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

NOTE: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For [content] which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

NOTE: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

DISCUSSION NEEDED We need a discussion to happen before notes are developed, based on some circumstances I have been thinking about:

• Many products with really small size screens (e.g. printers) may not have available memory to support reflow capabilities or another version of the layout that supports single-direction scrolling.
• Some screens are so small that horizontal and vertical scrolling are needed to access all of the capabilities of the device.
• What is the equivalent size of 320 x 256 CSS pixels (and how do you measure that) in non-web documents or software?
• Do non-web document authors have any control over scrolling, or is that strictly up to the document viewer (user agent)? I have seen PDF documents that are provided book-style where the pages flip. Zoom on those causes reflow issues.
  **NOTE: **I've started a discussion thread regarding caveats and thoughts about applying this SC to non-web documents and software.

Some potential notes for the WCAG2ICT guidance:
Note: Some software runs on technologies where there is no method to zoom content to 400% or reflow content, or the screen is smaller than a mobile device; it would not be possible to meet this success criterion with those technologies.
Note: It is likely that for software there will be more frequent cases where two-dimensional layout are required for usage or meaning.
Note: CSS pixel measurements would have to be converted to another measurement for non-web technologies.

dfn-CSS-pixel

From the WCAG 2.2 definition for CSS pixel:

visual angle of about 0.0213 degrees

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display. User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

DISCUSSION NEEDED
What does a CSS pixel mean for non-web technologies? Is there a conversion that makes sense and how is that done?

[mraccess77]

The big discussion here is does this mean the whole window or just blocks of content. How something like this could be tested may give us insights into what could be required.

For example, if you treat each block of content as being the testing unit you would then need to measure that block of content with something like a pixel ruler and then adapt the view in different ways if it did not fit or meet an exception to determine if it could pass.

[oh185014]

Small nitpick, but "Except for parts of the content which require two-dimensional layout for usage or meaning." isn't bulleted in WCAG 2.1

[maryjom]

@oh185014 Thanks. Fixed.

[maryjom]

Taking into account information and others' input in the GitHub discussion thread, and the discussion we had in the 23 February meeting.

Here's my first attempt at draft WCAG2ICT content:

1.4.10 Reflow

From Success Criterion 1.4.10:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

NOTE: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

NOTE: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

Guidance When Applying Success Criterion 1.4.10 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.10 (also provided below), replacing “CSS Pixels” with "device-independent pixels" and “web content” with “content”.

With these substitutions, it would read:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 [device independent pixels];
• Horizontal scrolling content at a height equivalent to 256 [device independent pixels].

Except for parts of the content which require two-dimensional layout for usage or meaning.

NOTE: 320 [Device independent pixels] are equivalent to a starting viewport width of 1280 [device independent pixels] wide at 400% zoom. For [content] which is designed to scroll horizontally (e.g., with vertical text), 256 [device independent pixels] is equivalent to a starting viewport height of 1024 [device independent pixels] at 400% zoom.

NOTE: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

For non-web documents:

Note 1: If the document type or the user agent don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

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.

Note 3: See also the discussion on Closed Functionality

---

In the Key Terms section add a definition for device independent pixels.

device independent pixel

visual angle of about 0.0213 degrees

Note: This unit is density-independent, and distinct from actual hardware pixels present in a display. The physical size of a device-independent pixel depends on the assumed viewing distance between the user and the hardware.

Example: In the case of a mobile phone, the assumed viewing distance is considered to be an arm's length, which is around 28 inches (71 cm). At that viewing distance, the size of a device-independent pixel is 0.26 mm.

---

In Appendix A: Success Criteria that are Problematic for Closed Functionality add the following bullet and explanation:

• 1.4.10 Reflow - because the text reflow support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.10 in a closed environment may place a much heavier burden on the content author, especially when there are memory-constraints. Additionally, some products with closed functionality have very small screens where two-dimensional scrolling is required for usage of the software functionality.

[maryjom]

Survey opened for initial draft, due 5 April.

[mbgower]

I commend the TF for working through this tough SC. @rachaelbradley, I hope some of the concepts in the discussion are incorporated into WCAG 3.0 migration considerations. I added a WCAG next label to it.

[mitchellevan]

Regarding #98 (comment)

For non-web documents:

Note 1: If the document type or the user agent don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

Issue: Some PDF user agents provide reflow and others do not. Some "document types" of PDF support reflow and others do not. Need to clarify this situation.

Proposed: If there is no available user agent for the document type, such that the combination of the user agent and the document type support reflow, then the two-dimensional layout exception applies.

For non-web documents:

Note 1: If a document type and its available user agents don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

Relevant: w3c/wcag#814

[mitchellevan]

The "device independent pixel" definition is on the right track, but I have concerns which we can discuss on the conference call.

From #98 (comment)

device independent pixel

visual angle of about 0.0213 degrees

Note: This unit is density-independent, and distinct from actual hardware pixels present in a display. The physical size of a device-independent pixel depends on the assumed viewing distance between the user and the hardware.

Example: In the case of a mobile phone, the assumed viewing distance is considered to be an arm's length, which is around 28 inches (71 cm). At that viewing distance, the size of a device-independent pixel is 0.26 mm.

Nit: Better to say "in the case of a mobile phone app"

My concerns for discussion:

• I'm unclear whether it's necessary to rename "CSS pixel" to "device independent pixel" if the essence of the definition is unchanged.
• As I've shown, Android defines a device independent pixel. It turns out to be 1/160 of inch or 0.15875 mm, not 0.26 mm. iOS and desktop operating systems also define the device independent pixel. I suggest we use those platform definitions when they exist, and fall back to viewing angles otherwise.

[patrickhlauke]

As I've #101 (comment), Android defines a device independent pixel. It turns out to be 1/160 of inch or 0.15875 mm, not 0.26 mm.

note that these definitions don't necessarily match the reality of different physical screen dimensions between devices. they're an approximation/idealised measure at best (just like CSS pixels, which can vary wildly between different monitors/devices)

to take an example: pick up two different android (or even iOS) devices with differing screen sizes, and measure (with a physical ruler) the size of interface components defined in dps (or Apple "points"). they will vary.

[mitchellevan]

Edits and questions for non-web software

From #98 (comment):

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.

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?

[mitchellevan]

Today I filed w3c/wcag#3151

Is it useful to clarify this also in a note for WCAG2ICT?

[mitchellevan]

As I've #101 (comment), Android defines a device independent pixel. It turns out to be 1/160 of inch or 0.15875 mm, not 0.26 mm.

note that these definitions don't necessarily match the reality of different physical screen dimensions between devices. they're an approximation/idealised measure at best (just like CSS pixels, which can vary wildly between different monitors/devices)

to take an example: pick up two different android (or even iOS) devices with differing screen sizes, and measure (with a physical ruler) the size of interface components defined in dps (or Apple "points"). they will vary.

@patrickhlauke I agree that's a true statement. However, I'm not clear if you are advocating for or against my suggestion. Would you prefer that WCAG2ICT use or not use platform-defined dips when evaluating mobile and desktop software for 1.4.10?

[mitchellevan]

Responding to closed functionality in #98 (comment)

1.4.10 Reflow - because the text reflow support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.10 in a closed environment may place a much heavier burden on the content author, especially when there are memory-constraints. Additionally, some products with closed functionality have very small screens where two-dimensional scrolling is required for usage of the software functionality.

I'd like to add something like this:

Compared with other non-web software, closed functionality is more likely to prevent users from adjusting the size of application windows and content.

Also rephrase so we're not comparing closed functionality to web, but comparing it to non-closed software.

[patrickhlauke]

I'm not clear if you are advocating for or against my suggestion

not making any statement for or against. just pointing out that definitions that try to pin things down to a definitive size as measured on screen will almost certainly only be idealised/not correct...

[WayneEDick]

The assumption for 1.4.10 was that if a user agent does not reflow then a failure on that agent will not fail the criterion. However, if another user agent does reflow for that data type, the developer is required to reflow on that user agent. Here is an example: PDF will reflow in Acrobat if the file is formatted correctly. So, on Acrobat the PDF should word wrap. However, many math papers that are written to PDF from TeX or LaTeX. This uses the Knuth-Plass algorithm to justify pages. Because PDF is printer oriented, spaces are not used to separate some word sequences. Instead, the words are positioned to fit exact adjustments of white space. There is no white space character between them. When a user agent tries to reflow the words in these sequences are concatenated into a long jumble of meaningless letters like: longjumbleofmeaninglessletters . The document will not reflow in a functional form on a user agent that supports reflow. Thus, it does not meet 1.4.10, because the authoring tool fails to produce reflowable text. Best, Wayne

[samogami]

device independent pixel or css pixels needs to be taken up as it own topic. Some systems don’t have idea of pixel size, not changeable by author. This is a case where web requirement is not reverent and should not be applied. There are already other requirements for text size outside of wcag2itc. In addition to adding note 3 from MJ comment into this SC the closed products section a general note about pixels should be added as it css pixels or device independent pixels are in other SC also.

[maryjom]

device-independent pixel
visual angle of about 0.0213 degrees

Note: This unit is density-independent, and distinct from actual hardware pixels present in a display. The physical size of a device-independent pixel depends on the assumed viewing distance between the user and the hardware, as well as the platform. The platform may have its own standard device-independent measurement.

Example: In the case of a computer screen, the assumed viewing distance is considered to be an arm's length, which is around 28 inches (71 cm). At that viewing distance, the size of a device-independent pixel is 0.26 mm.

[mraccess77]

While the definition is appropriate I can't help but wonder given that this SC is aimed at users with low vision that we should at least acknowledge somewhere that people with low vision would likely not be using the device at such a viewing distance. but that this is the standard viewing distance.

[maryjom]

@mraccess77 I think that is true for web content as well - not just the application of WCAG to non-web ICT. If it is generally true for all tech, any statement to that effect should go into WCAG. WCAG's definition is based on the CSS reference pixel and that is how it is defined.

[bruce-usab]

+1 for discussion on CSS reference pixel / device independent be address separately from 1.4.10 Reflow.

The conversation at the end of today's call was on reflow. From recently proposed above:

For non-web documents:
Note 1: If a document type and its available user agents don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

I came away thinking the note should be more narrow, and also make refence to the fact that not all file format are accessibility supported. I propose for consideration something like:

Note 1: An example of non-web documents which require two-dimensional layout for usage are nature photographs.

Note 2: Not all document types support reflow, and some document types do not support reflow on some user agents. Such limitations are not under author control, but that does not mean that the content requires two-dimensional layout for usage or meaning. Such limitations might mean that the document type is not accessibility supported.

[maryjom]

@bruce-usab I like the direction you're heading with this. I have some tweaks in mind. Here's a proposed adjustment to your suggestion.

Note 1: Examples of non-web documents which require two-dimensional layout for usage are nature photographs or documents intended only for printing or archival of print format material.

Note 2: Reflow may not be accessibility supported by all document types and user agents. Such limitations are not under author control, but this does not mean the document requires two-dimensional layout for usage or meaning.

[mbgower]

I thought I'd provide a reality check on recent discussion. Namely, as someone with a decent background understanding of Reflow who has not heavily followed this thread, neither version of Note 1 makes it clear to me 1) why a nature photograph would be excluded, nor 2) why it would be considered a non-web document.

So i think you need a bit more explanation in those notes. First, there is no reason that a photograph cannot be reduced to fit the available space. It may become so small that it is essentially a thumbnail which cannot serve the same purpose as a high-resolution archival photo, but there is no reason that the representation of any image cannot fit in a confined space.

WCAG uses the phrase

images required for understanding (such as maps and diagrams),

In the context of WCAG2ICT, I'd be inclined to work in some concept of "original size" or even "high resolution" to try to tackle the context that information must be presented beyond the physical dimensions of a device to achieve its intended function. I assume that's where you were going with "archival", but I think it needs a bit more. I also think an example of an actual non-web document format would be useful.

Maybe something like:

Examples of non-web documents which require two-dimensional layout for usage, and so require horizontal scrolling, are high resolution archival photographs or documents stored in a ___ system.

[patrickhlauke]

In the context of WCAG2ICT...

I'd again wonder if a fundamental concept/clarification would not benefit from being ported directly "upstream" to WCAG 2.x rather than just in WCAG2ICT

[mraccess77]

Re @mbgower's suggestion - it depends - SC 1.4.8 covers some of this but only horizontally. Also, the 400% could be achievable for other formats like documents - but perhaps not for UI layed out text on small screens in software - however, on larger screens I would not want to lose the 400% where it is possible. I wonder if there is some other measure such as percent of screen width or height that could be used.

[maryjom]

I did some calculations with CSS reference pixel size and the angle of viewing to see what that might mean as far as physical size for a 320x280 viewport. Doing the math (assuming I did it right), the viewport size for reflow doesn't seem to make sense outside of the web. How would you actually test this? Many software windows don't resize to the calculated dimensions. I have a table of use cases with the calculations I made. I checked the reference pixel size compared to the one in the CSS reference pixel size explanation to ensure I was calculating that part correctly. After that, you simply multiply by 320 to get the vertical dimension and 256 to get the horizontal dimension.

After doing the math using the reference angle and the law of sines, calculating reference pixel size = .000376378028864 * distance from the device. Multiply that by 320 to get the horizontal size, or by 256 to get the vertical size. I looked up reference distances for each use cases from ergonomic data. These are all ranges, as everyone has a slightly different distance they use their device that might be optimal for that user.

The following table contains the resulting calculations. I'm not sure how to take into account the difference in platform display density, as these results seem to be quite small in size and on my Mac, I am unable to resize windows as small as the resulting viewport size.

Example use case	Viewing Distance	Reference pixel Size	Viewport Vertical size	Viewport Horizontal size
Phone	16-18 in (40.6-45.7 cm)	.0060-.0067 in (.153-.172 mm)	1.93-2.17 in (4.89-5.50 cm)	1.54-1.73 in (3.91-4.40 cm)
Tablet	16-30 in (40-76 cm)	.0059-.0111 in (.151-.286 mm)	1.90-3.60 in (4.82-9.15 cm)	1.52-2.88 in (3.85-7.32 cm)
Desktop display	20-40 in (50-100 cm)	.0073-.0148 in (.188-.376 mm)	2.37-4.74 in (6.02-12.0 cm)	1.90-3.79 in (4.82-9.64 cm)

[patrickhlauke]

Note that the SC assumes that the user has heavily zoomed in. so the CSS pixel will be much larger (physically, as measured on screen) than the "ideal" CSS reference pixel.

i.e. start with the assumption that the user is sitting at desktop distance from a large-ish monitor set to 1280x1024, and that that is the "ideal" reference pixel size (approximetly, as of course no monitor manufacturer etc works towards any such unifying measure, and since the viewing distance is variable anyway). now zoom in by 400%, now the same monitor is showing 320x256 pixels...

[mraccess77]

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.

Regarding the pixel viewing distance and size - either users with low vision will be closer or they will be using magnification so the typical viewing distances and pixel size would not apply directly but are needed for this group. 400% is 16x the area.

[patrickhlauke]

(generally, my advice is to never actually try and work out the "physical"/"real world" measure of something like CSS pixels, particularly using the "intuitive" definition given in the CSS spec. too many variables and assumptions, and that's even before you also dive into user settings - e.g. what resolution the user has set their OS to work at - or zoom factors/magnification software/etc ... you just end up going in circles/staring into the abyss)

[maryjom]

@patrickhlauke So does that mean I should multiply times 400%?
@mraccess77 From what I read in other issues on testing this SC, most will resize their window or viewport size to be equal to 320x256 pixels. Not sure how you know or adjust to that size for non-web software or documents so I was hoping to get some calculation where a tester can easily know how to make the necessary adjustments to test the content in those cases.

I do understand that pixel sizes are different on different systems and pixel density also figures into that equation. I have been going a bit in circles, not knowing how to apply this SC outside of the web. The TF cannot rewrite the SC to talk about 400% zoom - which only the understanding describes. Additionally, 400% zoom is not necessarily supported by all platform software. There are no CSS pixels outside of the Web and I don't think testers generally know what to do to test this SC outside of the web.

[patrickhlauke]

worth adding here that the SC doesn't use CSS pixel sizes for reasons relating to physical size or anything, but simply because it's the common basic building block for all web-based measurements (all other units of measure are anchored on the CSS pixel for on-screen content). how this sort of thing would then translate to other types of display (like a very rough LCD matrix display) is...an interesting challenge. Maybe even in those cases it needs to refer back to whatever the base unit for that particular display is (320 LCD "dots" by 256 LCD "dots").

(as an aside, again this is where the weird definition of 1.4.10, which prescribes a specific width or height, rather than a "down to" measure, will cause even more problems, as in theory it would then only apply if the LCD display in the example above has an exact width of 320 LCD "dots" for horizontal content / 256 LCD "dots" for vertical content ... when really you'd want to be able to say something more like "user shouldn't need to scroll horizontally AND vertically when the display is at least X by Y" ... related: w3c/wcag#698)

[mraccess77]

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.

[mbgower]

It sounds like @mraccess77 (comment), @patrickhlauke (comment) and I (comment) are all contemplating a similar question -- that would need to be addressed by AGWG, and likely for 3.0:

Can we make the magnification/no scrolling requirement based on screen dimensions?

when really you'd want to be able to say something more like "user shouldn't need to scroll horizontally AND vertically when the display is at least X by Y" ... related

I wonder if there is some other measure such as percent of screen width or height that could be used.

Maybe we can come up with a formula based on percentage of the viewport area.

Again, this is obviously off the table for WCAG2ICT, but this requirement is going to be migrated to 3.0 in some form, and it would be good to resolve it in some way that is scalable while reasonably addressing need.

[maryjom]

Thinking only about device-independent pixels (or CSS pixels), and what exactly that means for calculations is definitely an issue. CSS pixels, is used in several places in WCAG 2.2:

• 1.4.10 Reflow
• 2.5.8 Target Size (Minimum) - where the size of the target is at least 24 by 24 CSS pixels. If under that size, the elements must be positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target
• 2.5.5 Target Size (Enhanced) Level AAA - where the size of the target is 44 by 44 CSS pixels
• 2.4.11 Focus Appearance Level AAA - where the area of the focus indicator is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component
• The definition of CSS pixels which states:

visual angle of about 0.0213 degrees

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display. User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

• The first note in the definition of general flash and red flash thresholds which states:

NOTE: For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi is known to be lower, and thus more conservative than the nominal CSS pixel resolution of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds.

• The example for the definition of perimeter which states:

EXAMPLE 16: The perimeter calculation for a 2 CSS pixel perimeter around a rectangle is 4h+4w, where h is the height and w is the width. For a 2 CSS pixel perimeter around a circle it is 4𝜋r.

Maybe we simply use the definition of device-independent pixel (above) and state that a device-independent pixel's size is dependent on the software platform's definition. In Android, it is called a "density-independent pixel (DP)" and in Windows it is called "device-independent pixel". I don't know if a DIP in those platforms is actually defined based on the viewing angle (I haven't found documentation about what it is based on.)

Some software doesn't reside on top of a software platform (e.g. in closed functionality software), so there likely isn't a device-independent pixel defined, and likely no measuring tools to help. In the case of 1.4.10 Reflow, I'm not sure how a software author would make the appropriate measurements and calculations to ensure is met. In many cases, closed functionality software doesn't have the capability of increasing content size to 400% or maybe not at all.

[patrickhlauke]

In Android, it is called a "density-independent pixel (DIP)"

super small nit...it used to be abbreviated to dip originally, but they've now moved to shortening it to dp in their documentation (though the term is still density-independent pixels)

EDIT: found https://developer.android.com/training/multiscreen/screendensities and I think this part is relevant here:

One dp is a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160 dpi, or the "baseline" density).

Taking "one pixel on a medium-density screen" to (very handwavily) mean "one CSS pixel" (because that, roughly, matches reality - and keep in mind that on mobile/tablet, they don't have to deal with things like users changing the OS resolution etc), this shakes out nicely to basically saying that on android, read the SC to mean "320 dp / 256 dp" effectively)

[maryjom]

@patrickhlauke Fixed the nit in my above comment.

[mapluke]

Regarding #98 (comment)

For non-web documents:Note 1: If the document type or the user agent don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

Issue: Some PDF user agents provide reflow and others do not. Some "document types" of PDF support reflow and others do not. Need to clarify this situation.

Proposed: If there is no available user agent for the document type, such that the combination of the user agent and the document type support reflow, then the two-dimensional layout exception applies.

For non-web documents:Note 1: If a document type and its available user agents don't provide reflow capabilities, then the document content requires two-dimensional layout for usage or meaning and would meet the exception of this Success Criterion.

Relevant: w3c/wcag#814

The original WCAG note is all about content that "requires two-dimensional layout", and allowing that type of content not to be reflowed. In my view, it was never intended to allow user agents or document types to not reflow content just because they cannot. But that is what the note seems to be saying when it says that all content that such user agents or document types encounter "requires two-dimensional layout".

[detlevhfischer]

@maryjom

Not sure how you know or adjust to that size for non-web software or documents so I was hoping to get some calculation where a tester can easily know how to make the necessary adjustments to test the content in those cases.
(...) I have been going a bit in circles, not knowing how to apply this SC outside of the web. The TF cannot rewrite the SC to talk about 400% zoom - which only the understanding describes. Additionally, 400% zoom is not necessarily supported by all platform software.

@mitchellevan

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.

In iOS and Android, platform software zoom does not trigger reflow. One could argue that 1.4.10 would only apply to software / apps that offer their own zoom functionality independently of the platform software.

On the other hand, when looking at iOS and Android apps, there is the equivalent of viewport changes when devices are rotated, or apps are viewed in splitscreen views. Some apps do offer content reflow depending on orientation or screen size. So this could be tested to say: If your app is laid out for a wide screen view (tablet) it must reflow to 320px (roughly: portrait view of a small screen smartphone).

Taking the requirement narrowly, the immediate problem is the lack of current mobile devices with a reported viewport size of 320 CSS px: https://viewportsizer.com/devices/ starts at 360 px. If adaptation to a portrait orientation is tested at all, it seems reasonable to adapt to existing, i.e. available, sizes, e.g., by adding a note that the reference to 320 px should be extended to "320 px or its nearest available equivalent" (if we can't have "up to"). All that assuming that there can be cases where testing reflow would make sense because content actually does reflow (in orientation changes, split screens, or app-based zooming).

We have tried to adapt 1.4.10 to app testing in our test step, in German (I am far from certain that it stands up to scrutiny, and comments are welcome).

[bruce-usab]

Just above Detlev suggests:

adding a note that the reference to 320 px should be extended to "320 px or its nearest available equivalent"

I agree with the discussion (in this thread, and elsewhere) that this is really an upstream problem for WCAG (2.x or 3). But in the context of WCAG2ICT, do we need more than this?

[mitchellevan]

Of cause, taken the requirement narrowly, the immediate problem is the lack of current mobile devices with a reported viewport size of 320 CSS

Actually, all Android devices that I've tried do offer a viewport width equivalent of 320 CSS pixels. See #101 (comment)

I've just now tried it on an iPhone SE with the "Display Zoom" setting enabled, as in these screenshots. This changes the screen resolution from its default of 375 CSS pixels to a width equivalent of 320 CSS pixels. This is not to be confused with the Accessibility "Zoom" setting, which is a magnifier and does not change the screen width equivalent.

That said, other platforms do have such a limitation. Certainly macOS does. So I support this language:

320 px or its nearest available equivalent

[mitchellevan]

Corrected link for iPhone "Display Zoom" screenshots: https://www.google.com/search?q=display+zoom+iphone&tbm=isch

[maryjom]

Guidance for CSS Pixel definition and notes for non-web documents approved in the 6 July meeting, so I'll be closing individual issues #162 and #159 used to develop and track those aspects. The other two individual issues for non-web software and closed functionality are still being worked.

[maryjom]

The TF had a number of consensus decisions regarding the definition of "CSS pixel" in the context of non-web technologies as well as on the notes and guidance for non-web documents and software. The consensus decisions were logged between 8 June and 13 July on the WCAG2ICT decisions WIKI page. The AG WG reviewed 1.4.10 Reflow in the 3rd content review and approved the content on 25 July with the agreement that there would be editor's notes to ask for examples and scenarios where this SC might be impossible to meet.

@mbgower If there are changes in the guidance needed in WCAG2ICT because of Issue 3322, please open a new issue for the WCAG2ICT TF to handle. Glad to see that the SC may be clarified in WCAG due to our analysis.