Testing 1.4.10 Reflow: No equivalence of testing at 320px or 1280px with 400% zoom?

[detlevhfischer]

So far we have assumed that reflow may be generally tested either at a viewport width of 320px or at 1280px and 400% zoom (the Note in 1.4.10 claims equivalence). In practice, it turns out that some sites seem OK when viewed in a narrow browser window but are pretty unusable on the desktop with 400% zoom (because there is a lot less vertical space). An example is https://www.bmu.de/ where at 400% zoom the navigation drawer is sticky / unusable - the lower items do not fit the viewport and cannot be scrolled to.
Would this fall under the (planned, pencilled in) "Failure due to content disappearing and not being avialable when content has reflowed"?

[mraccess77]

My personal opinion is that while this is potentially an issue under the WCAG CR for accessibility supported it is not specifically caught by 1.4.10.

I believe SC 1.4.10 should not be tested with zoom but instead should be test with the browser developer toolbar set to a width of 320 -- as that is what is called for by the SC. What we do is open the dev toolbar and dock it to the right. Then resize the view to 320CSS pixels wide. This is what is covered by the SC. We also test text spacing in this view with Stylus.

When we created this SC I had indicated that there would likely be issues that happen with zoom that would not be caught by this SC -- the original intention of the SC was to zoom to 400% of the default -- but in the end the 320 bit was the only thing we could get enough consensus on so we took what we could get.

I agree that your example is an issue for users and I run into this very issue on some sites.

[patrickhlauke]

Would this fall under the (planned, pencilled in) "Failure due to content disappearing and not being avialable when content has reflowed"?

Not quite sure it would. Note that the issue here is not so much that the reflowing itself causes the problem though, but rather that the site didn't adapt itself to fit into a 320x180 (or thereabouts) viewport size, which is extremely small and likely an unrealistic target for most sites.

[patrickhlauke]

In other words, the site reflowed correctly. But it didn't work at 400% resize, which is double the amount of the mandated 200% for text resize. So this straddles the line between the two SCs, but I don't think the site necessarily fails here...it's more that it fails in the artificial setup of the test (where you have a landscape-oriented browser which, when zoomed to 400% on a 1280 screen to test for the horizontal reflow, ends up having an effective height of 180 pixels or less.

[detlevhfischer]

@mraccess77 I did not get the impression that the approach you follow in testing is mandated - the note stating the equivalence would seem strange if it was. 400% zoom at desktop is of course one of the main use cases for LV users - unsticking the header at a narrower breakpoint (there is even a Technique for that already, I believe, even though I can't see it in the google sheet right now) should be easy enough to make the reduced height workable.

@patrickhlauke The effective height could be larger than 180px, depending on the size of your monitor.

Whatever we decide, it might be worthwhile stating in the Understanding text that issues such as this do not fall under the SC (I am not yet convinced that they don't, though).

[mraccess77]

@detlevhfischer I'm trying to understand your question about what's mandated. Are you saying using the dev toolbar is less than sufficient or requiring more than what is sufficient? I agree it doesn't address the 400 zoom issue -- but that didn't make it in the SC unfortunately. Maybe something for 2.2?

[detlevhfischer]

@mraccess77 I assumed neither option (reducing viewport site to 320px or zooming in 400% at 1280px) was mandated and both would be valid ways to test Reflow, but the way you put it sounded as if the 320px approach was the only sensible way. Not using zoom one will not come across the issue reported. I agree however that it might be a stretch to fail a site for a fixed menu that does not fit the little vertical space there is (though I am not sure this would warrant a stand-alone new 2.2. SC).

[mraccess77]

Using the dev tools to bring up a sidebar and resize the viewport to 320CSS seems like it would meet the requirement. I'm not talking about using the RWD/mobile device feature of dev tools -- but simply resizing the browser content view within the browser.

[patrickhlauke]

yup, you essentially want to achive 320 css px width (and check that text is correctly reflowed even at that size). whether that means on a 1280 monitor to have the browser maximized, then zoom in 400%, or make the browser window half the width of the monitor, and zoom in 200%, or being able manually make the window 320 px wide (depending on browser/number of tabs open, there's a certain minimimum width that you often can't get past, which is why this option doesn't always work out exactly).

[scottaohara]

Marking this issue as resolved per the updates to the Reflow understanding doc (#4055) - particularly the new section added "Acknowledging viewport vs resolution discrepancies" that points out that a display resolution of 1280x1024 will not give someone a viewport of 320x256 when the browser is zoomed in 400%.