Can browser dev tools > device toggle be used to test SC 1.4.10 Reflow

[mraccess77]

Do folks feel like browser dev tool device toggles such as in the one in Chrome developer tools set to 320 width for horizontal test sites can accurately be used to test this SC?

[alastc]

I think: Yes, strictly.

However, I wouldn't generally advocate that because I think it makes sense to test reflow, text-size and text-spacing together.

[patrickhlauke]

jumping into this old issue, but as it's still open: noting here that the reflow aspect is not necessarily about mobile or not, but just about the viewport width. whether that is changed/set as a result of emulating a mobile device, or by zooming to 400% or so on a 1920x1080 maximized browser window, or by resizing the browser window until the viewport is at those key minimum sizes...it's all the same (all other things being equal, e.g. there's not silly user agent string detection that happens on the site that makes it switch to a different layout when it think the browser is now "mobile" versus "desktop").

[JAWS-test2]

it's all the same (all other things being equal, e.g. there's not silly user agent string detection that happens on the site that makes it switch to a different layout when it think the browser is now "mobile" versus "desktop")

This may be true for many browsers, but not for the most used browser: Chrome. In Chrome it makes a difference whether I view a page at 320 px or 1280 px at 400% zoom or whether I view the page on my smartphone or the smartphone emulation of the developer tools on the desktop chrome.
This can be seen e.g. well on any technique or failure page of the WCAG: the two nav areas are enlarged accordingly when zooming in the desktop browser, but not in the mobile view.

The question would be:

• what is relevant to the test. Both views or just one of them?
• do both, only one or no view constitute a violation of SC 1.4.10? (in both views there is no need to scroll, but in the desktop view the text breaks up incorrectly because the nav area becomes too wide, in the mobile view the nav area is not readable because it is too small)

[alastc]

This can be seen e.g. well on any technique or failure page of the WCAG: the two nav areas are enlarged accordingly when zooming in the desktop browser, but not in the mobile view.

Ah, looks like those pages are missing the meta-viewport setting to enable responsive view on mobile. That's a bug for those pages, and you'll see the techniques index and WCAG spec do have that setting. It does not undermine Pat's point.

what is relevant to the test. Both views or just one of them?

By the letter of the SC, I'd say that it fails on the "Content can be presented" aspect of the SC, without setting the content to allow for reflow it would fail if you are including mobile user-agents. (Because the default view is around 960px wide when you don't have the meta viewport set.)

I could see someone argueing that the content does allow itself to be reflow and it is a browser-bug, but it is a well established browser feature/bug.

[alastc]

Adding @michael-n-cooper, we have a build process issue where meta-viewport is not added to the technique pages so mobile browsers get the desktop view.

[TestPartners]

I don't think it's valid to test this in a 320px wide window in a desktop browser because it is not the same as testing on a 320px wide mobile device or on a 1280px desktop browser window at 400% zoom.

The main difference is the effect of sticky components. Sticky headers, footers and other components can substantially or completely obscure the rest of the content on a 320px wide mobile device or on a 1280px desktop browser window at 400% zoom. By contrast, they barely obscure anything in a 320px wide window in a desktop browser because the page is about four times longer.