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 or address in some form (see: this comment) - there are others, but this lists at least references all the ones that were considered while working on this PR.
• add all the new graphics to this PR / render properly (further revisions can be made if people would like different/more consistent examples - but as of now at least all examples for this pr have been created)
• follow on issue for creating more examples/techniques

The latest updates will be visible via this preview link of the understanding doc

Closes #3121

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	cc708e7
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/67cb2614694485000807b115
😎 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 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
• 1.4.10 Reflow needs a preamble #3121 - the intent is being significantly updated, as well as a lot of other information added, which should sufficiently address this issue.
• What does "content" mean in SC 1.4.10 Reflow #2073 - this PR helps clarify what 'content' Reflow is meant to be concerned with.

[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.

[kfranqueiro]

Understanding pages typically share a consistent structure with regard to level 2 headings, and therefore the table of contents. This page deviates significantly:

• There are no Benefits or Examples sections, though I suspect these subjects are covered within the sections that do exist
• There are a number of level 2 headings unique to this page, which surface in the table of contents

This may cause a jarring experience for folks used to navigating the rest of the Understanding pages, including the previous version of this one.

Is this divergence in h2s fully intended? Is there any possibility of avoiding it?

[scottaohara]

@kfranqueiro I had made this comment about the benefits section for thoughts from the task force. @giacomo-petri responded, but i suspect many others didn't notice

here's the text of the comment, as it's likely hidden to most due to the number of comments/commits in this PR

question for the group: but do we need the benefits section in this understanding doc anymore? i realize most (but not all) SC understanding docs have a benefits section - but this one in particular is rather diminutive, redundant to the "why it's important" in the in brief section - and i'd submit a lot of the content, starting with the intent, litters in benefits.

so yes, benefits and examples are spread throughout the doc (though there is also still an examples section, and it is in the TOC)

Re:

There are a number of level 2 headings unique to this page, which surface in the table of contents

and yes, this was done on purpose and had been discussed in the task force meetings as being done to make the TOC more useful, particularly since this doc is now so much longer than most other understanding docs.

[kfranqueiro]

Thanks @scottaohara for catching me up / reminding me, and sorry for what probably felt like a redundant question while I had my maintainer hat on.

[scottaohara]

no problem @kfranqueiro - it was good to call out, as many people coming into this thread will not have had any of that context / could likely miss the comment about removing benefits (since it's hidden by default). so thank you for bringing these points up

[murata2makoto]

First, modern Japanese text uses both vertical and horizontal writing. Moreover, a single web page can incorporate both writing directions.

This might already seem complex, but there are even more intricate aspects to consider. Even if an entire web page uses vertical writing, it may have multiple columns, ensuring that only vertical scrolling is needed instead of horizontal scrolling.

Here are two examples:

https://www.renhai.org.tw/AboutUs
https://yamaei-unagi.jp/

That said, a web page with reflowable Japanese text never requires both horizontal and vertical scrolling simultaneously.

[GreggVan]

Oh my

Thanks @murata2makoto

not so simple indeed. these links we should capture someplace where we can easily look at them when we are creating our new rules and thinking on scrolling and wrapping etc.

@murata2makoto do these pages behave well for scrolling and wrapping? if not - do you have some reference pages we can use that do behave well?

[mbgower]

First, modern Japanese text uses both vertical and horizontal writing. Moreover, a single web page can incorporate both writing directions.

This might already seem complex, but there are even more intricate aspects to consider. Even if an entire web page uses vertical writing, it may have multiple columns, ensuring that only vertical scrolling is needed instead of horizontal scrolling.

@murata2makoto
Your first reference overall seems to match the guidance provided in the updated document. For instance, the page reflows to only use vertical scrollbars. In the section where blocks of content are presented side by side and require horizontal scrolling, it is provided in a carousel format, where each segment of content fits horizontally within the viewport. I'm not sure the chunks of content in this carousel fully meet the desired outcome for Reflow -- as I zoom up the page towards 400%, the content written in the carousel reflows to fit horizontally but exceeds the viewport vertically, causing me to scroll up and down to see the text -- but the basic approach is there. (I'll note that there are also failures on the page to do with the fact the automatic cycling of the carousel cannot be paused.)

Figure 1. Horizontally written Japanese is displayed in sections (delineated by text on a white background), each of which can be viewed independently in a carousel. The text fits horiztonally in the viewport, but the height of the section exceeds the veiwport.

For your second example, when the page is magnified to 400%, the top navigation remains in view the whole time, taking up a sizable portion of the viewport and preventing vertically written text from displaying inside the remaining space. If this top bar was removed/collpased, it appears to me (without doing actual measurements) that some but not all the vertically written sections would meet the Reflow requirements.

Figure 2. A magnified page, showing a top level banner (with a beige background and hamburger menu) that takes up more than 1/3 of the viewport. The vertically written characters do not fit vertically in the remainder of the viewport. However, if the banner were removed, no vertical scrolling would be necessary to read.

Other parts of the page do not accomplish this past about 200% zoom. In the following screenshot, the text in the area with the whitebackground fits at 200%, but beyond that, even if the top banner were dismissed, the text would not fit vertically in the viewport without scrolling. I also find that the text isn't really doing much reflow. The heading is repositioned to proceed the chunk at the next level of navigation, but the lines do not seem to flow to a set vertical height.

Figure 3. The same page at a reduced zoom level, showing that the top navigation is written horizontally, with a section of vertically written text (on a white background).

Figure 4. The same section of the page at 400%. Only a few characters appear below the banner. More than 3/4 of the vertical lines appears above the visible viewing area.

Your examples are interesting to me from the perspective that although the text is vertically written, it is often designed to fit within a vertical page flow. The language of the success criterion is written from the assumption that vertically written text would not be presented on a page that scrolled vertically, but on a page that scrolled horizontally. Thus, the language of the success criterion seems to be passed even where IMO, the page is failing to allow vertical text to be read without scrolling "in the direction of text".

Vertical scrolling content at a width equivalent to 320 CSS pixels;
Horizontal scrolling content at a height equivalent to 256 CSS pixels.

---

That said, a web page with reflowable Japanese text never requires both horizontal and vertical scrolling simultaneously.

Agreed. Even in the final image with the text on a white background, the user never needs to scroll horizontally to read this. But the intended purpose of Reflow -- that a user does not need to scroll vertically to read vertically written languages nor need to scroll horizonally to read L2R/R2L languages, and -- is not met.

@scottaohara you should review. I'd also ask @MakotoUeki to weigh in on this.

[mraccess77]

I think the assumption was that horizontal text would be part of a page that had vertical scrolling and that vertical text would be part of a page that had horizontal scrolling - thus the wording of the SC. If vertically scrolling text also can be scrolled vertically then that doesn't seem to be clearly covered by the wording.

[yamahige]

@murata2makoto do these pages behave well for scrolling and wrapping? if not - do you have some reference pages we can use that do behave well?

How do you like these small and simple pages:

• Horizontal text in a horizontally scrolling page
  https://codepen.io/yamahige/pen/jEOmZVm
• Vertical text in a vertically scrolling page
  https://codepen.io/yamahige/pen/yyLbvaz

Please view those pages in the "Full Page" view and shrink the browser window to small. The browser controls the width of the column, sending the overflow characters to the following line and sending the overflow lines to the next column.

[scottaohara]

@mbgower @murata2makoto - I think Mike's assessment is spot on. I went over these two example pages and from what i could tell the first example seemed like it could end up being a good example of how to meet Reflow - as the text that was written vertically changes to be horizontally presented at smaller viewports.

The second example, imo, passes Reflow while not meeting the intent. The page only scrolls vertically - but the text is presented vertically. Someone may have to scroll back and forth (up/down) to read a section of text.... but they don't have to scroll in two dimensions AND the vertical text is not horizontally scrolling (so 320 width applies, not 256 height) - so per the wording of the requirement (which is out of scope for this PR) this passes.

[bruce-usab]

Discussed on backlog call 3/7 and everyone for publishing. TF facilitators discussed after call, to either give more review time or go forward with publishing, and advanced this PR to Fully Reviewed. Thank you @scottaohara and everyone for the feedback!