Reflow test does not take in consideration the size of the screen

[carolinacrespo]

Reflow test does not take in consideration the size of the screen

I have found 2 different behaviors when testing 1.4.10 Reflow.

1) Test using chrome dev tool. Resizing the browser 320x256 px I get a failure:

2) Test with arc toolkit, it passes:

Expected behavior

The size of the screen should be fixed otherwise; different screens would get different behaviors.

Screenshots

If applicable, add screenshots to help explain your problem.

Version information

• Browser and version:
• ARC Toolkit version:

Additional context

Add any other context about the problem here.

[ferllings]

@carolinacrespo Could you provide your testing url?

When the Page Reflow is activated your browser is resized to 1280px, with 400% zoom, to achieve the same result than 320px, 100%. Is it not working for you?

[poorgeek]

@matatk Carolina said you might have some ideas on how we can reproduce this issue? Any details can you can add?

[matatk]

Here's a summary of what Carolina, Mike, and I found when testing.

tl;dr: the 320x256 viewport setting via the DevTools' responsive mode is the simplest and most reliable method, and the only one that's needed.

There are two methods proposed in the KB and ARC to do the testing:

1. Set the viewport, via browser DevTools' responsive view mode, to 320x256 CSS pixels.

2. Size the browser window to 1280x1024 (IIRC) and zoom to 400%.

The KB points out that, when done correctly, these are identical - but it is not easy to do method 2 correctly because:

1. There are cross-browser differences in how zoom is handled in the DevTools' responsive mode. E.g. in Firefox, if you press Ctrl/Cmd and + to zoom, it just enlarges the rendering of the responsive viewport; it doesn't resize it.

2. Sizing the browser window may be subject to UI scaling in the user's OS/browser, so you may not end up with a window that is actually the right size. (We need to do more testing on this, but it seems to be an issue.)

Therefore we recommend only using method 1. (It would be good to get to the bottom of point B above too, though, but we ran out of time.)

Some people have said that they don't like using method 1 because the viewport is then really small. This is easily solved by using the zoom function in the responsive view mode (this is usually a zoom control that is right next to the X and Y textboxes, or in the case of Firefox, you can just press the zoom keyboard shortcut).

[ferllings]

@matatk Thanks for the clarfification. I see what you means now, so it's not an issue with toolkit itself, but with the technic used.

If the problem is with the 400% zoom, I can try to resize the browser to 320x256, but I'm not sure how it will works with the Toolkit panel attached.

I'm also trying to find alternatives, but:

• It doesn't seems possible to trigger the devtools responsive mode via Toolkit
• Simpling Resizing the element will not work

[matatk]

It looks like APIs such as Window.resizeTo() are intended to take CSS pixels as the units (direct spec link about units), but they don't account for the browser UI. I did find a post on StackOverflow that talks about taking UI into account, but it's pretty old, and I wouldn't assume we can rely on it (and this may well be a moving target).

There is an interesting new VisualViewport API that can do things like report the size in CSS pixels, but can't resize the viewport. But maybe it could be used in conjunction with resizeBy()?

We think the problem with manually resizing the browser window is that OS-reported pixels are not necessarily CSS pixels (due to HIDPI/OS scaling). The 320x256 procedure is simpler and more reliable if being done manually (and you can enlarge it, to make it easier to see, but that part varies slightly across browsers).

[poorgeek]

In reading over this and discussing it amongst the team, I recategorized this as an enhancement given that method which is implement in ARC Toolkit isn't broken, it's just not the preferred solution for in testing for page reflow.

One thing we considered as part of this decision was whether or not we should also add a disclaimer or additional guidance with ARC Toolkit that let's the user know that in some cases, the page reflow may be better tested using the browser's Responsive Design Mode.

[brothercake]

The 256 in that is a red-herring. A page doesn't have to be tested at 320x 256 (or zoomed equivalent), it has to be tested at 320 or 256 depending on the primary flow of the page content. The 256 is only applicable for pages that scroll sideways and not down, whereas for most cases we test pages that only scroll downwards, so the only relevant viewport dimension is the 320 width.

[matatk]

@brothercake: I've been thinking on what you say regarding only one of the two given dimensions being required (and, as most content scrolls only vertically, in most cases this will mean that a 320 CSS pixel width is the key measurement). I do see what you're saying, though I also don't see the harm in testing at 320x256 CSS pixels, as doing so wouldn't change the result, and always doing the test the same way makes the procedure simpler. If you're concerned about a 320x256 viewport being too small (which is understandable) it is possible to enlarge the rendering of the viewport (without making it a differently-sized viewport) in some browser's DevTools.

What do you think?

Whilst considering this, I thought about two particular types of content we often encounter, and whether it would be absolutely required to test that content with the viewport sized to 320x256 CSS pixels. Am curious as to what you think about these...

1. Does a carousel that implements its own "sliding" mechanism, but doesn't make the page wider, count as scrolling content (the SC says "content", not "pages").

   (I'm torn on this: I first assumed WCAG was talking about OS-native scrolling, so one may think a custom carousel is out, but equally it's probably quite likely that such a carousel wouldn't fit within 256 CSS pixels vertically, and would therefore cause an accessibility barrier in practice, so maybe it is intended to be covered. Need to check the WCAG repo issues to confirm.)

2. We often see code samples marked up in verbatim blocks, to preserve spacing and line breaks. They often scroll horizontally, using OS-native scroll bar widgets. Does this mean that such a code block could not exceed 256 CSS pixels high? It sounds like this may be the case, but would the escape clause for the 2D presentation being important override this, because of the semantic importance of line-breaks?

   (I assume this content would be excepted, but equally I can see it being hard to use, as someone who regularly encounters these things. Again, wondering what you think, and would be good to check the WCAG repo thoroughly.)

(I did actually check the WCAG repo issues section for some of these, using the following search, but haven't had time to dig through all the issues yet: https://github.com/w3c/wcag/issues?q=is%3Aissue+1.4.10+320+256

[dabrams888]

Throwing in my 2 cents for the 256 concern. I strongly believe that we should keep this in our test procedure as it helps catch cases where there may be a loss of content due to fixed/sticky positioned content that, when zoomed, takes up the majority of the viewport. The value of 256 can be used as an approximation of the device's vertical resolution when at 400% zoom (even though that exact value is a little dated since most 'desktop' devices these days have a vertical resolution larger than 1024). So even though it's not horizontally scrolling content being tested, it can tell us if someone with a zoomed device due to low vision would be restricted from accessing all of the information. Or at a minimum, it could tell us if we need to dig further.

[dabrams888]

As far as the Toolkit feature for reflow goes, I'm wondering based on this conversation if customers would be better served if this feature were removed in order to avoid false positive failures of 1.4.10.

[mitchellevan]

I agree with @dabrams888's last comment. I would go further if I could.

that exact value is a little dated since most 'desktop' devices these days have a vertical resolution larger than 1024

True, screens today are taller than 1024 in physical pixels, but the aspect ratio is more relevant than the physical height. Desktop screens nowadays are usually less tall than 1280 x 1024 when you look at the ratio of height to width, and viewports are even less tall than that because of toolbars.

This is why I've argued before that 256 is actually too tall for 1.4.10 testing (in horizontal content with vertical scrolling). I might not have convinced anybody from a 1.4.10 conformance perspective, but those arguments should at least help strengthen our will to hold the line at 256 height, not something taller.

[brothercake]

@matatk You ask an interesting question there, that I don't have a definitive answer to.

My feeling about this is that inner scrolling regions should be assessed separately. If the page only has vertical scrolling, but there's an inner region that only has horizontal scrolling, then that passes, because no single container has both vertical and horizontal scrolling.

But does 1.4.10 apply to inner scrolling regions at all? If an inner scrolling region has both horizontal and vertical scrolling (as some online code editors do) then is that a 1.4.10 fail, or does it count as an essential exception if the scrolling is there to avoid code wrapping and improve comprehension?

To question 2: There was a conversation about this in Teams last year, and initially I said that it does count as an exception on the grounds that it's not technically possible to solve it any other way. However I was put in my place on that one -- it is possible. See the Teams thread for details. So from that I would conclude that it's not an essential exception and must be assessed for 1.4.10.

To question 1: I would count any kind of sliding mechanism as proxy scrolling, so I think 1.4.10 also applies there.

[cpandhi]

As i have observed, you have to use vertical scrolling to get to the inner regions with horizontal scrolling. Agree! to question 1: I would count any kind of sliding mechanism as proxy scrolling, so I think 1.4.10 also applies there.

[dabrams888]

My feeling about this is that inner scrolling regions should be assessed separately. If the page only has vertical scrolling, but there's an inner region that only has horizontal scrolling, then that passes, because no single container has both vertical and horizontal scrolling.

Is this too strong of an assumption to make globally? Depending on the user's zoom level I feel like it's not unreasonable to expect that introducing an inner scroll region could still be problematic. CodePen for example.

If you view that example at 320x256, the horizontally scrolling section fits within the vertical space of the viewport. If we tested this inner scroll as its own sample independent from the full page, it would technically pass 1.4.10 because each card only needs horizontal scrolling to read. However, line tracking is still a nightmare. So it doesn't escape the underlying problem 1.4.10 is trying to address.