What does "content" mean in SC 1.4.10 Reflow

[JAWS-test]

1.4.10 Reflow specifies that "content" may not be scrolled two-dimensionally at 320px width or 265px height (with a few exceptions).

But what is "content" in the context of 1.4.10?

1. the entire page
2. a contiguous block of text
3. a paragraph of text
4. a visual page area that could be marked up with a landmark region, for example (e.g., the main menu in the navigation region)
5. a column in the page layout
6. something completely different?

The answer seems important to me, as it seems that a page is allowed to have several different contents that have different scrolling directions (see #2063 (comment) and #2063 (comment))

A few examples where I don't know if 1.4.10 is met or not:

1. the menu must be scrolled only horizontally, the rest of the page only vertically.
2. a text with 2 columns, in each column I have to scroll only vertically, but to get to the next column I have to scroll horizontally
3. text that needs to be scrolled horizontally at 320px, but not vertically, although the text is horizontal (e.g. a text in English language)
4. the same text as in example 3, but it has to be scrolled horizontally already at 1280px, but not vertically (and at 320px as well, although with more scrolling effort due to the 400% zoom)
5. a form with 2 columns, which has to be scrolled vertically and horizontally, but horizontally only to get to the 2nd column (the filling direction in the form is from top to bottom, then to the 2nd column).
6. a form with 2 columns, which has to be scrolled vertically and horizontally, but horizontally only to get to the 2nd column (but the filling direction in the form is from left to right, i.e. you have to switch constantly between left and right)
7. the same form as in 6. but it must be scrolled already at 1280px between the two columns

There is a definition of "content" in WCAG glossary which in my opinion, however, does not help in answering the question:

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions

[alastc]

But what is "content" in the context of 1.4.10?

In the context of WCAG, everything within the page.

1. the menu must be scrolled only horizontally, the rest of the page only vertically.

If a chunk of content (e.g. a menu) scrolls horizontally, it should meet the second bullet on vertical height.

2. a text with 2 columns, in each column I have to scroll only vertically, but to get to the next column I have to scroll horizontally

If the entire page is scrolling in both directions, that's going to fail. It's an odd and problematic case (as discussed elsewhere), but caught by the wording.

3. text that needs to be scrolled horizontally at 320px, but not vertically, although the text is horizontal (e.g. a text in English language)

If it's scrolling horizontally, it would need to meet the 256px height bullet.

4. the same text as in example 3, but it has to be scrolled horizontally already at 1280px, but not vertically (and at 320px as well, although with more scrolling effort due to the 400% zoom)

Same as 3.

a form with 2 columns, which has to be scrolled vertically and horizontally, but horizontally only to get to the 2nd column (the filling direction in the form is from top to bottom, then to the 2nd column).

Same as 2.

5. a form with 2 columns, which has to be scrolled vertically and horizontally, but horizontally only to get to the 2nd column (but the filling direction in the form is from left to right, i.e. you have to switch constantly between left and right)

Same as 2.

6. the same form as in 6. but it must be scrolled already at 1280px between the two columns

Same as 2.

[mraccess77]

@alastc "If the entire page is scrolling in both directions, that's going to fail. It's an odd and problematic case (as discussed elsewhere), but caught by the wording." I think we need to have the group vote on their interpretation (if it hasn't already occurred) because there doesn't appear to be consensus on this. This may simplify testing and failure but fail blocks of text that in themselves are readable without two way scrolling - which was the impetus for the SC. I can live with either direction the group goes - but clarity would help interrater reliability.

[JAWS-test]

@alastc

I don't really understand the answer: is "content" now the whole page or a part of the page (because you write about "content" and "chunk of content").

I also don't understand exactly the answer to the examples. I interpret your answer like this:

• A page that has a vertical and horizontal scrollbar on the outside is always wrong (as long as none of the exceptions like table etc.).
• A page that has only an outer vertical scrollbar is not wrong, even if page areas have inner horizontal scrollbars (as long as those page areas don't have vertical scrollbars).

Is that correct?

[alastc]

is "content" now the whole page or a part of the page (because you write about "content" and "chunk of content").

I wonder if there is a language issue here? Let me try a metaphor: Consider the page as a bucket, and the content is water in the bucket.

You can talk about the content as a whole, all the water in the bucket. Or you could talk about bits of it, like the top 1/3rd of the water in the bucket. It is all content (water), but you can take it as a whole or as parts.

A page that has a vertical and horizontal scrollbar on the outside is always wrong (as long as none of the exceptions like table etc.).

Paraphrasing the SC text: "Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions ... Except for parts of the content which require two-dimensional layout for usage or meaning."

So the exception applies to parts of the content. Therefore a table (wrapper) can have scrolling, but that exception doesn't apply to the rest of the content on the page.

That's why I said if the whole page has scrolling (e.g. at 320px wide) that would be a fail.

A page that has only an outer vertical scrollbar is not wrong, even if page areas have inner horizontal scrollbars (as long as those page areas don't have vertical scrollbars).

Agree. A page which scrolls vertically can have inner areas which have horizontally scrolling (and fit 250px height).

[alastc]

Jon wrote:

I think we need to have the group vote on their interpretation (if it hasn't already occurred) because there doesn't appear to be consensus on this.

Ok, I'll raise a question. Drafting the question, I think it would be:

---

A question has been raised in #2073 about whether having scrolling in horizontal and vertical directions would always be a fail of 1.4.10 Reflow. The scenario would when: "a page has 2 columns, and for each column a user can scroll vertically, but to get to the next column you have to scroll horizontally."

Does that scenario fail 1.4.10? (Please comment with reasoning)

[mraccess77]

If I understand @alastc comment - In the example of video streaming site - you could have horizontally scrolling widgets with videos (as long as they are not > 256px high) and you could also have page level vertical scrolling. But you could not have page level horizontal scrolling and pass. Is that what you said?

I'd assume that if there was a horizontal scrollbar that appears for the page but it didn't actually need to be used that it would be ok. I see this sometimes with pages the scrollbar appears but it is not needed as there might just be some extra padding on the side causing it.

[patrickhlauke]

the distinction between "the page as a whole" and "parts of the page" become a weird "at which point is something a part of the page, or the whole page. we've already previously discussed (and allowed) tables with bidirectional scrolling and even carousels/sliders (as long as individual cells/slides/etc fit within the viewport). what if the entire page is just a carousel of this sort? and if this is conceptually ok, is there a difference between a "real" carousel and a layout with two or more vertical columns, requiring vertical scrolling for the column, and horizontal scrolling to go from column to column, provided each column fits within the viewport? the difference here seems to be functionally non-existent.

[JAWS-test]

The content=water metaphor doesn't really help, in my opinion, because if I can divide content like water, then a page consists of lots of individual pixels that have no scrollbars and no reading direction.
Or does the content consist of letters? And the letters form a line that is read from left to right - and even if this has to be scrolled horizontally, this would not be a problem because a line of text is horizontally scrollable content. After that comes the next line of text - and all lines of text have to be scrolled vertically, but that would not be a problem either because that is a new level of content. And then comes a new column of text - the next higher level of content - and it has to be scrolled horizontally again. This is certainly not what is meant by SC 1.4.10, because the point is to avoid scrolling when reading a text block.

A page that has only an outer vertical scrollbar is not wrong, even if page areas have inner horizontal scrollbars (as long as those page areas don't have vertical scrollbars).

Probably this definition is not correct, because if a page contains text and a table, then it should not matter whether the table has to be scrolled horizontally with an inner or outer scrollbar, as long as the text does not have to be scrolled horizontally.

Perhaps the following is meant by 1.4.10:

• A page may contain any number of inner and outer vertical and horizontal scrollbars (but only one scrollbar in one direction at each content).
• but it is not allowed that I scroll e.g. first downwards, then to the right and then upwards again (to perceive the right area from the beginning) and then downwards again, then to the left again to continue downwards
• but it is only allowed that I scroll down, then to the right and then further down (as it would be possible with the menu bar or with the video carousels at Netflix).

[JAWS-test]

Let's take a concrete example to illustrate my question: https://codepen.io/jaws-test/pen/gOxboYW

Would this page be ok because it has 3 different levels of content:

• Level 1: the whole page, is only scrolled vertically
• Level 2: the only horizontally scrollable parts of the page (with grey background), like Netflix (except that Netflix has videos here and no text blocks).
• Level 3: the text blocks (with black border) that are only scrolled vertically.

Result:

• I can read every text block without horizontal scrolling.
• To move from text block to text block, I have to scroll horizontally
• To move from each area with text blocks to the next area with text blocks, I have to scroll vertically
• But I never have to scroll down, then to the right and then up again.
• The scrolling effort without zoom and at 400% zoom does not differ qualitatively, but only quantitatively.

Now, on the other hand, the example https://codepen.io/jaws-test/pen/xxLbpZb, in which only the text blocks are higher.
Result:

• I can read every text block without scrolling horizontally (but I have to scroll vertically inside and outside, which is laborious, but not forbidden by the wording of 1.4.10).
• To move from text block to text block, I only have to scroll horizontally. However, to get to the beginning of the text block, I also have to scroll vertically. 1.4.10 forbids this.
• To get from each area with text blocks to the next area with text blocks, I have to scroll vertically (which is fine).
• I.e. I have to scroll several times first down, then to the right and then up again.
• The scrolling effort without zoom and at 400% zoom differs qualitatively and quantitatively.

In the last example https://codepen.io/jaws-test/pen/rNzapWX, the scrolling effort is qualitatively the same at 100% and 400%, i.e. I have to scroll up and down and to the right several times regardless of the zoom. This would not be an accessibility problem in itself, but it is still a violation of 1.4.10 because content has to be scrolled vertically and horizontally.

By the way, all three examples do not violate the initial intention of SC 1.4.10: Enable reflow within text so that scrolling after each line is not necessary

[workday-accessibility]

Hello everyone, we wanted to check in on what was decided from the survey?

This thread hasn't been updated since 2021 and there doesn't appear to be a change in the WCAG 2.2 documentation for 1.4.10 to add clarity. It's still unclear if the SC requires only scrolling in one direction for the entire page or if distinct areas with 1 dimensional scrolling is allowed as long as the user does not have to scroll in 2 dimensions to read the content.

[bruce-usab]

@JAWS-test the concrete examples are appreciated. The WCAG2 Issues TF will continue to iterate on guidance on reflow. We discussed very briefly a couple of your examples on the call today.

Let's take a concrete example to illustrate my question: https://codepen.io/jaws-test/pen/gOxboYW

That's a pass. It is essentially the same scenario as a two-dimensional plane of thumbnails, but only using text. See the example video selection page, in Alastair's comment on issue 3378.

Now, on the other hand, the example https://codepen.io/jaws-test/pen/xxLbpZb, in which only the text blocks are higher.

That's a fail. A set of narrow columns means lots of vertical scrolling while reading one column, then horizontal scrolling when trying to find the next column.

By the way, all three examples do not violate the initial intention of SC 1.4.10

I do not agree. The intention is to support fluid reading even with significant magnification. Your bulleted results reflect that.

[mraccess77]

Regarding columns/cells of text - maybe the difference here is that the columns are taller than 256 CSS pixels? We need to find a way to define when columns pass and when they fail.

[mitchellevan]

We need to find a way to define when columns pass and when they fail.

In a review of PR 3695 I've proposed applying SC 1.4.10 to each "section" as defined in WCAG.

Consider a scenario like @JAWS-test's https://codepen.io/jaws-test/pen/xxLbpZb ("in which only the text blocks are higher"). A page has three tall columns of left-to-right text, such as English. The columns appear side-by-side regardless of the viewport size. Each column is 320 CSS pixels wide. (In other words, the page is not mobile responsive, but each column is narrow.) In this scenario:

• If each section of content fits within a single column, then it would pass 1.4.10 under my proposed interpretation.
• But if a section runs to two or more columns, then it would fail 1.4.10 under my proposed interpretation.

I support @alastc's PR #3695 as modified by my review, not because it's perfect, but because it adds much-needed clarity. I could probably also accept any variant proposal, as long as it clarifies the intent of "content" for 1.4.10 and is consistent with normative WCAG.

[mitchellevan]

@mbgower's comment in 3599 is relevant. Michael's comment appears to support PR #3695.

@scottaohara's comment in 3599 with link to a demo is relevant. Scott's demo appears similar to the scenarios described in the current issue.