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?

[mbgower]

Here are some suggestions riffing off Scott's original

Goal
A line of text can be read without needing to scroll

What to do
Make lines of text reflow within the viewport

Why it's important (gotta try to get this one shorter!)
People who need bigger text find it difficult if they need to scroll sideways to read.

[mbgower]

So, a few basic goals of the In Brief material:

1. state the essence of the criterion simply
2. express the concepts briefly, in phrases that are 10 words or less
3. where possible/appropriate, use language/terms that complement, not simply parrot, the normative text

I won't bothering going into rationale for those reasons here (I can send you to background if desired) but overall, across the 7-dozen or so criteria, those goals are met. As we start trying to wordsmith, I wanted to ensure we were following the same style and directive as all the others.

---

@A11yTea

I am curious as to why the goal "Content can be enlarged without needing to scroll in two directions." was rejected.

First, scrolling up and down, is scrolling in two directions. Except on very short pages, a user is going to need to do that. So the phrase is not accurate, and potentially confusing/misleading. The normative text says "without requiring scrolling in two dimensions", which is an accurate way of describing the requirement, but it is not particularly easy for many to understand.

So the first challenge we face coming up with something is to make it true and at the same time easy to understand, and complementary to the normative text. It is not a simple task.

[mbgower]

if the In Brief assumes the exemption of non-text content

In what way does it do so? Focusing on text in the 'In brief' should not logically lead to a conclusion non-text is exempt. For anyone who forms such an impression, the 'In Brief' is immediately followed by the normative wording which explicitly states the criterion covers "content", states the exception, and gives examples of the kind of material that meets that exemption.

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

One of the curiosities of Reflow is that the word "essential" wasn't used. Instead, it is "required". The jury is out on whether that difference in language is a positive or negative (I suspect the latter), but the fact is that how something is designed does factor into this consideration. If the SC had used "essential" we would have a lot more ability to say 'you can do this another way, therefore this fails'. We lose some of that clarity with the undefined word "required" BUT we do gain an ability to take the design into account, for better or for worse. So, for instance the use of the word "requires" allows us to let tables be wider than 320px, even though there are ways to design large tables to make them consumable in chunks without what one would consider "scrolling". Just look at some of the stuff Apple came up with for their iOS design.

It's hard for me to imagine a design that requires a 1000px textarea. (I didn't bring up that example.) A textarea, by definition, accommodates variable sizing of content and should be able to be response. HOWEVER, I guess if someone puts in an image that is 1000px wide into a textarea, the textarea is going to probably either expand to that width to accommodate OR offer horizontal scrolling to accommodate that. So it bears thinking through.

I think a more likely scenario for exclusion could involve text inputs.

A financial entry system could require inputs wide enough to accommodate values in the billions -- accurate down to the cents. That would require an input that could contain 14 digits, plus traditional indicators for negative transactions and spacers, for instance: ($320,591,238,492.54). But even then, we're well within a 320px width.

But how about other situations where a long single string is need, which is not a word but something else that may contain special characters and needs to be contiguous, say a security hash? I think one could at least form an argument that that could require an input width that exceeds 320px.

On a simplistic level, text inputs only exist on one line so far as I know, so anytime a text input exceeds 320px, there is going to be a problem, no? I guess one can use responsive design to alter the text input to a text area to work around that, but that 'solution' does lead to some design oddities as well.

Figure 13 in the understanding document is a good example of non-text elements needing to reflow.

Figure 13 is interesting. I'd argue the main thing it is demonstrating is the failure of the text to display properly. I'm less certain that if the search input alone exceeded the width in the design that it would make a good fail example. I've seen search strings that have been truncated so that it was not actually possible to differentiate the results being displayed in the dropdown underneath, due to lack of horizontal space provided. So I can see situations where something wider may be necessary. There's probably a way to design around it.

still some disagreements about the criteria like the mention of inputs reflowing

Oh, there's always going to be disagreement, especially with the wording of this SC. The thing is, the more abstract the discussion is, the more opportunity for misunderstanding. That's why all the work Scott did on the Understanding document is so important. It provides more nuanced examples to respond to.

[A11yTea]

Headings are used below to simplify the reading of this message.

Let's close this issue

I would like to suggest that we close this issue. In Brief is non-normative and for my work I can just ignore them, they are not meant to help me as an auditor. I would be curious though to see their impact on the target audience of the In Brief but I think I am reading too much into it.

In what way does it do so? Focusing on text in the 'In brief' should not logically lead to a conclusion non-text is exempt. For anyone who forms such an impression, the 'In Brief' is immediately followed by the normative wording which explicitly states the criterion covers "content", states the exception, and gives examples of the kind of material that meets that exemption.

Its just through the focus on text properties and the In Brief is supposed to summarize the criteria. The focus on text as a way to summarize the whole criteria is where I get the assumption. But that could be just me. If its just me, then there is no point to discuss this further.

Reflow is a pain in the... (mini-rant)

Reflow has always been a pain for auditors and developers. If I conducted a poll, I predict that Reflow would surface as one of the most difficult criteria to tackle, alongside 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships. However, the real distinction between Reflow and 4.1.2 and 1.3.1 is that the latter are simply complex to test for criteria whereas the Reflow's primary issues arise from its fundamental requirements.

Many find it hard to believe when I say that Reflow is about specifically 320 CSS pixels (or 256) - nothing more or less. Counterarguments suggest it isn't realistic, with some assuming that Reflow merely denotes mobile or small screen accessibility. The clause "Except for parts of the content which require two-dimensional layout for usage or meaning" is a bit ambiguous however, luckily, the examples provided cover most 2D layout contents we typically encounter, such as images, video, games, presentations, data tables (excluding individual cells).

I am aware of the section in the understanding document "Why specifically 320px and 256px?" but "the value of 320 CSS pixels for vertically scrolling content was chosen as a reasonable minimum size that authors can achieve" is still an arbitrary choice. I am not against this, I know that realistically a decision has to be made here. Its just that I get a lot of grievances from the developers about this.

We need just a little bit more specificity in the Understanding document

The new additions are fantastic. Thank you so much for the great work scott! However, this discussion suggests that we may require a bit more clarification regarding non-text content reflows, especially for inputs. I'm considering creating a new issue for this subject. I believe if we can address the concerns that @mbgower and I have brought up in this discussion, it could resolve a notable gap. Such as adding directives like:

• Buttons and controls should (or should not) be accessible without two-dimensional scrolling unless they must remain visible with other content, thus necessitating a "two-dimensional layout for usage or meaning."
• In order to conform to reflow, forms should be designed with labels stacked above their respective inputs, and inputs should be styled to fit the viewport.
  Quick question: Would it be a failure if a website has three content columns but, when reflowed, scrolling is required to access the subsequent column, even though each column can be read without 2D scrolling?

Exceptions?

It's hard for me to imagine a design that requires a 1000px textarea. (I didn't bring up that example.) A textarea, by definition, accommodates variable sizing of content and should be able to be response. HOWEVER, I guess if someone puts in an image that is 1000px wide into a textarea, the textarea is going to probably either expand to that width to accommodate OR offer horizontal scrolling to accommodate that. So it bears thinking through.

This is an interesting situation to think of. I would go with: the text within the text area should conform to 320 CSS pixels but the image does not, kind of like Figure 9. If that is possible. Like Outlook does it.

A financial entry system could require inputs wide enough to accommodate values in the billions -- accurate down to the cents. That would require an input that could contain 14 digits, plus traditional indicators for negative transactions and spacers, for instance: ($320,591,238,492.54). But even then, we're well within a 320px width.
But how about other situations where a long single string is need, which is not a word but something else that may contain special characters and needs to be contiguous, say a security hash? I think one could at least form an argument that that could require an input width that exceeds 320px.

That is a fair point, the idea here might be to go with a textarea for the hash and for the finances input, it might be to still have it within 320 CSS pixels, but you can scroll horizontally into it. (It would give you the same functionality than if it exceeded the 320 CSS pixels because you will scroll horizontally in either way.

I'm less certain that if the search input alone exceeded the width in the design that it would make a good fail example. I've seen search strings that have been truncated so that it was not actually possible to differentiate the results being displayed in the dropdown underneath, due to lack of horizontal space provided. So I can see situations where something wider may be necessary. There's probably a way to design around it.

We need answers on this.