1.4.10 Reflow In Brief leads to different conclusions about the criterion

[A11yTea]

Hi everyone, I have an issue with the In Brief of 1.4.10 Reflow since it leads me to a different interpretation of the criteria.
Here are my comments on each part:

Goal
Content can be enlarged without increasing line length.

Comment on Goal: I have no idea what this means, and how do I look for line length? What does line length mean?

What to do
Make lines of text reflow within the viewport.

Comment on What to do: So non-text content are exempt? Like inputs dont need to reflow? Why does the criteria use the term "content" and the in brief is not?

Why it's important
People who need bigger text find it difficult if they must scroll to read long lines.

Comment on Why it's important: I think that is okay, but I might suggest changing "text" for user interface or content

[scottaohara]

fyi, edited the original post by putting the in brief text into blockquotes, so that it is visually and programmatically easier to differentiate the quoted text from the comments about the quoted text.

[alastc]

The difficulty here is that the reflow concept is somewhat complex, and we can't fit that into the "in brief".

From your comments @A11yTea, it looks more like confusion than concluding something different from the SC text?

Goal: I'm not sure how else to say "line length", it's a fairly common term (e.g. wikipedia).

Personally, I preferred an earlier version which was something like:

"Content can be enlarged without needing to scroll in two directions."

However, there was a reason that wasn't used (I just can't remember what it was).

What to do: I think saying "content needs to reflow" would be more confusing, as that raises questions like "how do I reflow an image?". Is there a suggestion for this one?

Why it's important: I tried using "text", but it doesn't make as much sense when it continues to "read long lines".

Overall, given that the rest of that document is dedicated to explaining reflow in many scenarios, the job of the in-brief is to introduce the criteria. It doesn't replace the SC text, and it cannot be the full explanation.
I'm not sure whether there is a clear improvement to the in-brief from this?

[mbgower]

@A11yTea as part of @scottaohara's original changes to Reflow, he had suggested updating the In Brief to match the direction he was pursuing with the overall rewrite.
At the start of the Reflow update work, the In Brief text had been reviewed and approved by the Working Group relatively recently, yet the Understanding document had not been updated since 2018. We therefore tactically focused attention on the Understanding document. The PR ended up having over 200 comments and a lot of revisions, so I maintain trying to contain the scope was prudent.

Personally, I'd like to wait for more folks to consume the Reflow rewrite before trying to update the In Brief, but we can certainly start having some conversations and see where we get to.

Let me first respond to your questions.

"Content can be enlarged without increasing line length".
I have no idea what this means, and how do I look for line length? What does line length mean?

I don't think anyone loves the current goal wording, although it is largely correct (and maybe even clever). It's a classic situation where it is very easy to show what the goal is but hard to describe. If you have a 5" wide screen, the longest a line of text that can fit in the viewport is 5". As text increases in size, the length of a line of text cannot similarly increase -- since that would cause horizontal scrolling to occur. Instead, as each text character takes up more horizontal space, words that were initially on the same line are going to have to break across multiple rows to preserve the same 5" line length. See the Figure 2 video for what I hope is an obvious illustration of this.

If you come up with an easy way of expressing that, love to hear it.

"Make lines of text reflow within the viewport."

So non-text content are exempt? Like inputs dont need to reflow? Why does the criteria use the term "content" and the in brief is not?

The in brief uses "text" because the primary goal of reflow is to make it easier to consume text for users who use magnification. Hopefully that's obvious from the updated Understanding document. The normative wording has to be suitably broad in scope -- and the now-extended document covers a lot of edge cases and complex interactions. But we can focus on the main consideration with In Brief material, and at the heart of even the most complex interactions is usually a need to make text reflow appropriately.

In regard to your question on an input, the text label of an input would need to reflow -- and does automatically unless the user overrides it. If a button or text input -- the actual control -- is prescribed at a specific width that exceeds the viewport, then a case could be made it is exempt from reflow. It's a pretty unusual situation, since it's rare to have an input that exceeds 320 pixels in width.

Comment on Why it's important: I think that is okay, but I might suggest changing "text" for user interface or content

I certainly wouldn't want to change it to "user interface". That term does not even appear in the Understanding document. I don't really see that "content" improves this, especially because non-text content is much more likely to be exempted from the need to reflow.

[mbgower]

@scottaohara can you please post what you had for your initial suggestions for the Reflow In Brief? That seems like a logical place to start.

[TestPartners]

It's a pretty unusual situation, since it's rare to have an input that exceeds 320 pixels in width.

It's not rare in my experience. elements are often longer than that, albeit not usually much longer, perhaps 500px. However, it's very common for <textarea> elements to be as wide as 1000px. We encounter this in all sorts of web applications, especially procurement portals.

[scottaohara]

@mbgower here's the version of the in brief that i had, prior to reverting the text to what had already been accepted by the working group. not sure really what kind of "brief" summary will truly hit all the points... but as has been stated, that's not really the point of the in brief content, and at least this can serve as a start to further tweaks:

Goal
Content can be enlarged without needing to scroll in two directions.

What to do
Make long lines of text reflow within resized or zoomed in interfaces.

Why it's important
People who need bigger text find it difficult if they need to scroll back-and-forth to read multi-lined text.

[mbgower]

very common for <textarea> elements to be as wide as 1000px. We encounter this in all sorts of web applications, especially procurement portals.

But a design that requires a 1000px-wide text area is going to have to be exempt from a requirement to reflow without horizontal scrolling, right? The only possible way to show that is to have horizontal scrolling. Maybe I'm misunderstanding what you're asking.

[TestPartners]

very common for <textarea> elements to be as wide as 1000px. We encounter this in all sorts of web applications, especially procurement portals.

But a design that requires a 1000px-wide text area is going to have to be exempt from a requirement to reflow without horizontal scrolling, right? The only possible way to show that is to have horizontal scrolling. Maybe I'm misunderstanding what you're asking.

It's never essential - it's just how they design it.

[mraccess77]

In my opinion a 1000px textarea with text in it could fail unless there was some essential reason why it could not be adjusted smaller by the user/author.

[A11yTea]

Sorry for the delay in answering, I had to reread the Reflow understanding document a few times in order to give a proper response. So my understanding of the reflow criteria has not changed.

@mbgower I see your point with the line length and its very clever but again, its focus on a text-only property is problematic. And reading everyone's comments here seems to hint that there are still some disagreements about the criteria like the mention of inputs reflowing.

Figure 13 in the understanding document is a good example of non-text elements needing to reflow. The search input and the search button have to reflow, the buttons to access the next and the previous page have to reflow.

The In Brief are meant to be a more plain language version of the criteria, I am curious as to why the goal "Content can be enlarged without needing to scroll in two directions." was rejected.

For the "What to do", I have a few suggestions:

1. Adapt content to fit viewport, except when 2D layout is needed for comprehension or usage.
2. Style content to reflow within viewport, except when 2D layout is essential.
3. Style content to fit viewport, unless 2D layout is necessary.
4. Ensure content adapts to viewport size, except if 2D layout is needed for comprehension or usage.

Finally, I want to respond to:

I certainly wouldn't want to change it to "user interface". That term does not even appear in the Understanding document. I don't really see that "content" improves this, especially because non-text content is much more likely to be exempted from the need to reflow.

I can understand that non-text content is more likely to be exempted but if the In Brief assumes the exemption of non-text content then it will lead people down the wrong path. The In Brief does not replace the text of the criteria, but its much harder to unlearn a bad practice. If they enter with a bias that reflow pretty much only applies to text, then it might be confusing for them to properly understand this criteria.

The term "display" is used within the understanding document, here are a few suggestions for the "Why it is important":

1. People who need an enlarged display of content may become disoriented if they must scroll in two directions to use it.
2. If forced to scroll in two directions, people needing an enlarged display of content may become disoriented.
3. People needing bigger displays may struggle if they must scroll in two directions to access content.

[A11yTea]

In my opinion a 1000px textarea with text in it could fail unless there was some essential reason why it could not be adjusted smaller by the user/author.

Are you making the assumption that content can only fail if the text causes 2D scrolling? What if there is an icon button that is styled in a way that you have to scroll horizontally to reach it for vertical content? Would that be okay?

Also, what kind of situation would it be essential? Because if the user/author cannot make it smaller because, let's say, they are using a Commercial Off-the-Shelf product and therefore don't have control over that, I don't think it makes it not fail.

[mraccess77]

Are you making the assumption that content can only fail if the text causes 2D scrolling? What if there is an icon button that is styled in a way that you have to scroll horizontally to reach it for vertical content? Would that be okay?

As long as content can be presented without loss of information or functionality and not requiring 2d scrolling. I suppose it's possible in a situation like an editor if you couldn't access an icon to format the text and the text at the same time you could make an argument about loss of functionality.

[A11yTea]

Are you making the assumption that content can only fail if the text causes 2D scrolling? What if there is an icon button that is styled in a way that you have to scroll horizontally to reach it for vertical content? Would that be okay?

As long as content can be presented without loss of information or functionality and not requiring 2d scrolling. I suppose it's possible in a situation like an editor if you couldn't access an icon to format the text and the text at the same time you could make an argument about loss of functionality.

I think an editor fall into the exception: "interfaces where it is necessary to keep toolbars in view while manipulating content". But if it does not fall into the exceptions, then it should always reflow right?