Updated Reflow understanding doc

[scottaohara]

This initial commit takes the current draft from the google doc that had been worked on for quite some time now, and makes it into a PR for further editing and review.

Not all feedback from the google doc was directly taken/addressed, but there have been additional changes made that attempted to consider a good portion of the unresolved comments.

Marking this PR as a draft, as there is still work to do (and I also need to upload all the new graphics for the examples - and a few examples still need to be created, which are currently marked as comments in the HTML file).

• identify all the reflow related issues this PR will close :)
• add all the new graphics to this PR
• make sure the added graphics render properly
• add failure examples (per wg call requesting these)

Preview link

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	573a3dc
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/67643a57e2d34300088e48a3
😎 Deploy Preview	https://deploy-preview-4055--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[bruce-usab]

Briefly discussed on backlog call 9/6.

[scottaohara]

making notes of existing issues addressed with this PR (more to come):

• G206 seems to be allowing a failure to exist #656 - a few instances added to indicate that bi-directional exceptions apply to specific content and that content should have bi-directional scrollbars. Not the page. (though also have noted that bi-directional scroll bars at the page level do not necessarily mean that Reflow has been failed)
• 1.4.10 clarification (again) on "without loss of information or functionality" in relation to landscape aspect ratios #2043 and Reflow: Fixed Position Fields #366 addressed by some updates today
• clarify the 320 and 256 are separate from each other, regarding Reflow and Mobile Testing #3311 and Testing 1.4.10 Reflow: No equivalence of testing at 320px or 1280px with 400% zoom? #648
• Reflow and diverging content behaviour desktop vs. mobile #668 is addressed by the addition of the carousel example
• Semantic conveyed through Indented UI and Reflow 1.4.10 #887 is addressed by inclusion of new examples and supporting technique doc

[bruce-usab]

Discussed on backlog call 9/13, thank you @scottaohara! A preview is available but a reminder that the PR is still a work in progress. Most (but not all) content from Google Doc drafting has been pulled in and Scott has placeholders and inline notes-to-self. Looking really good! Outstanding question to @iadawn about replacing 4mb animated gif with an MP4, but where should a multimedia file go? TF would be okay with publishing without (and adding later) as the MVP need not be perfect.

[giacomo-petri]

While developing a technique for one of the new scenarios, I realized there might be an important edge case to consider during testing. Specifically, when we set the viewport width to 1280px, the browser's vertical scrollbar is included in this measurement.

For instance, if the viewport is set to 1280px and then zoomed to 400%, a card with a width of exactly 320px (without any margin) isn't fully visible horizontally because the vertical scrollbar takes up some of the available width. Does this count as a violation?

I intentionally designed the card to be 320px wide to fit the viewport exactly. While there’s some padding that ensures users can still read the content without needing to horizontally scroll, the card technically isn't fully visible within the 320 CSS pixels. This means a horizontal scroll is required to view the entire card.

The issue arises because the technique I was creating asks testers to set the viewport, check for scrolling sections, and verify that each individual panel fits without requiring scrolling. However, when the vertical scrollbar is present, this condition isn't fully met.

What are your thoughts on this? Would you consider it a failure?

Note: I think we need to clarify how we define the viewport; should it be based on document.documentElement.clientWidth (which would pass) or window.innerWidth (which would fail?)?

[scottaohara]

I intentionally designed the card to be 320px wide to fit the viewport exactly. While there’s some padding that ensures users can still read the content without needing to horizontally scroll, the card technically isn't fully visible within the 320 CSS pixels. This means a horizontal scroll is required to view the entire card.

at least the way a browser calculates its viewport, it's the area that is not considered part of the browser chrome (its ui). this is why it's a bit of a misnomer to say that a 1280 resolution with a browser set to 100% would always mean you could zoom in 400% to get a 320px wide viewport. That's not true in all cases. For instance, if i set my OS resolution to 1280px wide and i maximize my browser, if i'm viewing a page with a scrollbar the viewport actually has a max width of 1272px. This maybe is your issue with creating something that's 320px wide, but it not neatly fitting into the viewport - because your viewport isn't actually 320px?

but, regardless of that point, if the text is fully visible within the 320px wide area, but the border/padding of the card isn't completely in view - i don't think that should be considered a failure. One can read the content without having to scroll in two directions - that's the point of the SC.

[bruce-usab]

Discussed on TF call 12/13. Request to work on second sentence of Intent.

[scottaohara]

one thing that was briefly brought up in the last call was about how there should be a note/clarification added to acknowledge that a 1280x1024 viewport does not necessarily equate to using a 1280x1024 screen resolution.

here are some notes i've written on that for our own documentation on reflow, which i think would be helpful here;

For instance, with minimal browser chrome (address bar, bookmark bar and tabs at the top - and the viewport's scrollbar on the side) and the Windows task bar positioned at the bottom of the display – at a 1024 by 768 resolution the Edge browser when maximized has a viewport size of 1016px by 608px. There's already the issue that one would need to zoom in 320% to get a 320px viewport at 1024 - that not being a zoom feature provided by browsers. But with the actual viewport size, one would need to be able to zoom in around 317% to get a 320.5px viewport width.

At 1280 x 1040 display resolution, again a browser with the same setup would have an actual starting viewport of 1272 by 864px. At 400% zoom the viewport becomes 318 by 216px. Only 2px off from the normative 320px, but the height is far below the normative 256 – for when that sizing requirement is applicable. The only way to actually get a 320x256 viewport is to either have a larger resolution and resize one's browser so that the viewport is of the necessary base size - or at the 1280x1040 resolution - make the browser go full screen, so all the UI of the browser and OS is hidden...