Clarify Reflow expectations for sub-documents

[scottaohara]

Consider an example where there is a web page that has a nested document, rendered within an iframe. Due to the UI of the website (margins, padding, etc.) at a 320x256 viewport size, the iframe will be smaller than the minimum height/width requirements for reflow, resulting in bi-directional scrolling to view the content of the iframe.

the web page rendered in the iframe would meet Reflow if not for being nested within the iframe.

The primary site author(s) cannot modify the content of the iframe to meet reflow, and for the sake of this issue, let's assume they also cannot adjust the size of the iframe on their web page (i realize this could be a debatable topic - but please let's not do that).

The nested page author(s) have already met reflow, and they might not even be aware of where their page is going to be injected into, so they are not likely to meet viewport sizes below Reflow's requirements.

Does this scenario actually fail Reflow since the viewport of the iframe is actually smaller than the 320x256 minimum requirement?

[JAWS-test]

If all your preconditions are true, I don't see a violation of SC 1.4.10. However, I would expect that the iFrame should not have margins and paddings and that this is technically feasible, so I don't think your precondition is true and then I would say it is a violation of SC 1.4.10

[scottaohara]

Yeah. You’d think. But here I am asking people not to try and debate that exact thing because technically possible is not always possible in reality.

[alastc]

The comment I made in the meeting was:

From a WCAG 2.x point of view, conformance is at the page level, so when assessing pass/fail, it doesn't matter if nested content is from a different team, you're evaluating the page, and the content within the page.

Therefore the parent page would fail reflow.

After the meeting I scanned the understanding doc. I'm not sure it would help (in general) to add something to the reflow understanding document, as it applies across all the SCs. E.g. text-size and text-spacing, which are closely related, but everything else as well!

[mbgower]

Since I stupidly began talking about a relevant reflow question in an issue on Pointer Gestures, I thought I'd move almost my entire comment here, to keep for posterity.

@g-davies
Thank you for adding your information to the discussion and including the useful visuals.

The Task Force working on updates to the WCAG 2 guidance has been focusing discussion on the Reflow requirement, and your questions align with several points of discussion -- although after writing all this, I noticed that you were not specifically asking about Reflow but about Pointer Gestures! I'm going to let the following comments on Reflow stand, and then tackle Pointer Gestures (and Dragging) in a separate comment...

You may have noticed that the Understanding documents for WCAG 2.2 recently added an In Brief section designed to help guide users to the key take aways for each SC. Here it is for Reflow:

Goal
Content can be enlarged without increasing line length.
What to do
Make lines of text reflow within the viewport.
Why it's important
People who need bigger text find it difficult if they must scroll to read long lines.

This is the first published version of this In Brief guidance, and I anticipate it being updated, but hopefully it provides some key talking points. First, the primary motivator for this SC was to address the needs of users with low vision, who need to magnify text to read it. Such users were finding that a negative consequence of making text bigger was that if the text didn't reflow within the viewport, they were forced to read ptentially very long lines of text. The most negative outcome was that when they reached the end of one very long line of text and had to scroll a long way back to the start of the next line, they often lost their place -- either beginning to accidentally reread the prior line, or skipping lines. Hopefully the frustration and negative impact on comprehension is obvious.

Reflow, where the text gracefully fits within the viewport regardless of its size, is the simple solution to this. Hopefully the benefit of this on a traditional text-only page is obvious.

The problem, as you've noted, is that on applications and web pages where more varied content exists, chunks of information can be placed horizontally side by side in a carousel-like construction, with the intention that everyone will need to scroll horizontally (i.e., sideways) to see more than a few of the chunks. Such a construction does not need to place any additional burden on a user who makes their text bigger.

The task force is taking the approach that so long as each chunk of information meets the intent of the SC (i.e., one does not have to scroll to read any unit of information), horizontal scrolling is acceptable in most scenarios. In the examples you supply, the unit of information would be:

1. each hourly temperature in the scrolling list of hourly temperatures
2. each of the items in the scrolling list of recently played music
3. each of the users in the instragram scroll
4. etc

Hopefully that answers the overall question about whether any form of horizontal scrolling is allowed in Reflow.

---

I realize I just spent a lot of time not responding to your original question. As noted at the top, because the working group has been focused on Reflow, I saw your examples and began addressing them that way. I have removed this comment from the issue covering Pointer Gestures/Dragging, and moved it to the this reflow discussion.

[scottaohara]

might still be worth chatting about this a bit more then.

i also created another demo to talk through, rather than having people potentially imagine different things:
https://codepen.io/scottohara/pen/xxevMyM

test cases don't use an iframe, but the outcome to review is the same, regardless

[mitchellevan]

After linking from #2073 to a couple of relevant comments here, I'm closing the current issue. Alastair's whole-page conformance comment is the crux of the current issue, and otherwise it is the same as #2073.

If I was too hasty and there is a need to have the current issue still open, please reopen it.