Understanding 1.4.10 Reflow - additional clarifications esp. what is a fail and what is not

[shawna-slh]

Updated to clarify that this is a request for information to be added to the Understanding Document. More background in full Twitter thread.

From https://twitter.com/pauljadam/status/1277980249104367623 :

Yes clarifying the common misunderstandings would be excellent! ... For reflow need to define more of what exactly causes a fail. E.g. for reflow I'm seeing testers report things as failures when there is no visible text cut off from view during reflow but maybe just part of a square but not the actual text. Even the multiple ways to trigger reflow for testing seem confusing 320px vs 400% larger at 1028px?

[detlevhfischer]

The common desktop browsers do not support narrowing the viewport width to 320px: Firefox stops at a clientWidth (viewport width minus scrollbar width) of 435px and Chrome at 483. With Edge, you can get down to a clientWidth of 355. So the option of setting the viewport width with Firefox > Web Developer Toolbar > Resize to 320px (or 336px when accounting for the scrollbar) fails to show the page at the desired viewport width because the browser does not support such narrow widths. The DevTools function in Chrome to view the page at different device sizes (e.g. 320px for iPhone5/SE) does not produce the same layout as 400% Zoom from 1280px on the desktop.

The Firefox option "Responsive Design Mode" of the web developer tools provides a more accurate rendition of what the screen looks like when zoomed in on the desktop (check out google.com in both renditions) so this currently seems the way to go if you do not want to use Chrome, set width to 1280px, and zoom in to 400% (where you then often have to deal with the question whether fixed content would fail 1.4.10, and at what viewport height...).

I guess the question is still open how to handle the lack of usable space at zoomed in sizes, e.g. on a common laptop with a 16:9 display ratio where zooming in to 400% usually with browser maxed means that you have only have around 145px clientHeight (if you subtract what is needed for tab bar, menu bar and the like), meaning that even with modestly sized fixed content at top or bottom, there is hardly any space left for scrolling page content. Unless that amount of content (measured in body text lines or some other metric) is defined, there seems currently no normatively backed way of failing content if at least one line (of content? headings?) is fully visible. This was already discussed in issue https://github.com/w3c/wcag/issues/987 but it seems there was no resolution for this issue.

[detlevhfischer]

@slhenry As to your question whether it is OK to fail pages when bits of a square etc are cut off, I think that is down to a contextual assessment guided by the question: is the content still usable (which often means not cut off, readable). So I would focus of on the 'payload' of content, not on whether some edge is cut off; I would even accept cases where wrapping means that a small part of a long word is clipped if I can assume that as a whole, it is likely to be understood. So personally, I would probably not fail a page where the last n in the word 'internationalisation' is only half visible or even fully clipped.

[patrickhlauke]

Related: #1129 #1049 #668

[mraccess77]

@detlevhfischer I generally open the developer tools and dock to the tools to the side and then resize the window to 320CSS pixels for testing by dragging the split between the dev tools and the page. Are you saying this does not produce the desired results in Firefox?

[patrickhlauke]

The DevTools function in Chrome to view the page at different device sizes (e.g. 320px for iPhone5/SE) does not produce the same layout as 400% Zoom from 1280px on the desktop.

that shouldn't be the case, btw. got an example? is the site also browser-sniffing and reacting to what then looks like an iPhone? if so, suggest setting up a separate new "device" that simply has the desired screen metrics but no special user agent string.

And yes, if it's not possible to make the browser window as small/thin as 320px, you can always make it 640px and then zoom to 200%. Many different ways of getting to the 320 CSS px width to test in.

[detlevhfischer]

@mraccess77 That sounds like a clever approach - but how do you get feedback that you have reduced the size of the content part of the split window to exactly 320px?

@patrickhlauke Thanks for the tip about setting up "new device", I guess that should avoid UA specifics - will try it out.

[mraccess77]

Hi @detlevhfischer - for blocks of content or platform software you could use a screen ruler - I found one on the Windows store. I haven't figured out all of the details with dpi/scaling, etc. but with the screen ruler I'd imagine you could setup the pc to not use scaling and test in that configuration.

[patrickhlauke]

how do you get feedback that you have reduced the size of the content part of the split window to exactly 320px

in Chrome Devtools you get an indicator in the top-right (even when not docked). it disappears after a few seconds of not resizing.

beware though it currently doesn't take into account zooming (so only accurate when at 100%) https://bugs.chromium.org/p/chromium/issues/detail?id=1064297

[StommePoes]

^ I've been relying on that to set the width in Chrome, then I lay Firefox over it to try to set Firefox to that size, hoping it's close enough. I've been wondering if there's something better for Firefox though.

[mraccess77]

@StommePoes Firefox will allow you to resize the same way - the pixel width is not shown by default but can be turned on in settings and will be shown while dragging window with dev tools docked.

[yatil]

You all realize that Firefox (and every other browser) has a neat developer tool that lets you do that. Open the developer tools and click the devices icon in the tab bar on the right (looks like a phone before a tablet, as you can see in Patrick’s screen above, Chrome has the same icon & functionality – marked in the screenshot below as (1)).

You get a bar on the top of the content where you can put in arbitrary pixel values – like 320x900 to test – marked in the screenshot below as (2).

[StommePoes]

^ doesn't work for me, and never has. Using the device settings, setting a width of 1280, and then attempting to zoom causes a huge horizontal scroll, which isn't what I'm after when testing the non-320 part of Reflow (wouldn't surprise me if I'm Doin It Wrong, though).

I have used the device settings if I want to pretend I'm some kind of device that I'm not and play with touch settings though, which can be handy with some custom widgets with javaScripted touchstart/end junk.

[patrickhlauke]

don't set the device to 1280 and then zoom. set the device to 320? not sure what "non-320 part of Reflow" you refer to...am i missing something?

[mraccess77]

Hi @yatil I am aware of that - but since the SC doesn't mention mobile I'd prefer the width change only as I'm unaware of what other changes might be triggered by using that mobile view such as use agent changes. Also for me as a user who then needs to set text spacing and other things it just doesn't seem to perform as well as it those modes make it act more like a mobile. It's just my preference.

[yatil]

@mraccess77 If you don’t change the User Agent on your own – or use one of the built-in ones – that setting does not change the UA string. You can view the UA string by using Settings → Show user agent and clear it out to be sure.

[StommePoes]

@patrickhlauke I'm referring to the note in the SC.

I check both, but honestly it's also hard for me to see the 320 view (in this device emulator tool @yatil is talking about) esp after shortening the "height" value (which testers should be doing) since on zoomed desktops you've generally got a "landscape", not "portrait" view. Being able to set a desktop browser to 1280 reliably and zooming in 400% is easier to see, easier to test, and easier to note problems with stickies (on a tall 320 "portrait" phone, a sticky area may only take up a small portion of the screen, while on my zoomed desktop it's, like, half. Or in the case of something I'm testing right now, an entire chunk of content vanishes completely due to the page being made up of a sticky header and a sticky footer).

(Another example might be that, with a zoomed view, I can see that for example on Wikipedia, when hovering over a inter-wiki-link shows a popup for that page, it's often offscreen at my useful-zoom-level, while on mobiles either hovering's not a thing, or I can't figure it out on the browser tool.)

Since the Understanding page seems more specifically focussed on the zoomers, I believe it to be a failure of Reflow if a page becomes unusable with zoom even if seems okay on a 320px-width mobile device, or mobile device emulator.