Does "without loss of information" in 1.4.10 imply a certain minimum size for text and graphics?

[JAWS-test]

The intention of 1.4.10 is to enable 400% zoom. But this is prevented,

• on the one hand by the criterion itself, which only prohibits scrolling in 2 directions at 320 px.
• on the other hand by the Understanding text, which only refers to 1.4.4 regarding zoom and emphasizes that 200% zoom is sufficient.

But there is still the wording: "without loss of information".

If I don't scale the content at 400% zoom (so that it is not readable for visually impaired people) or reduce the content at 320 px (without zoom) so that it is unreadable for everyone, have I violated 1.4.10 because "loss of information"?

Or does "loss of information" only mean that content is no longer visible and not only unreadable because it is too small.

I give the following consideration:

• 1.4.4 requires zoom only for text and not for graphical content. So I can theoretically build an application in which the texts are displayed at 200% zoom to twice the size (and other content is not), and at 400% zoom there is no enlargement at all, because I have already fulfilled 1.4.4 at 200%.
• The website can determine whether it is a mobile device with a small display or a desktop device with a high zoom level. Thus, the website can deliver a responsive view with sufficient font size for mobile devices, but a scaled-down view for desktop devices at 400%, which is not helpful for the visually impaired. Again, it seems unclear to me how to test and what is and is not a violation of 1.4.10.

[patrickhlauke]

"loss of content" / "loss of information" means it's not there at all anymore. either the whole elements is not there, or the content is technically there but cut off and completely invisible. no, having text that didn't zoom to 400% is not a loss of content, as the content is still there and visible, just small.

[patrickhlauke]

also, if the content is not there on the same page, but is now still reachable from a sub-page (e.g. some content was visible right there in the page on larger viewport, but on smaller one it's only a link to another page that shows the full information, or a modal, or a disclosure widget, or similar), that also passes and is not a "loss of content"

[JAWS-test]

Ok, then what is the purpose of 1.4.10.?
Wouldn't 1.4.4 have been sufficient in conjunction with a criterion that requires not scrolling horizontally, no matter how wide the viewport is (down to 1280 px without zoom). The flexibility that 200% browser zoom does not have to enable 200% page zoom, but can also be achieved at 300% browser zoom, could have been included in the Understandig.

For me, it is quite absurd to write in the Understanding in the first sentence:

The intent of this Success Criterion is to support people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows

And then further down to find out that no zoom is required at all for 1.4.10, but only for 1.4.4 and there also only up to 200% (and only for text).

The most I would understand is that WCAG does not require 400% zoom at all. But only if a page allows 400%, then reflow must be. But no page has to allow 400% and so everyone can also save the trouble with reflow by simply not enlarging. Kind of like 1.4.12: I don't have to support or enable text spacing adjustment, I can even actively prevent it - but if I enable it, then I have to be careful to comply with the SC.

[bruce-usab]

The 400% is mentioned in the note to 1.4.10:

Note: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which are designed to scroll horizontally (e.g. with vertical text), the 256 CSS pixels is equivalent to a starting viewport height of 1024px at 400% zoom.

I think it fair to say, as you do, "WCAG does not require 400% zoom" because the specifics are a little more nuanced than that. 1.4.10 drills into the main obstacle: someone with low vision needing to manage scrolling in two dimensions. With the test conditions of the note, 400% zoom is required to be supported. The 400% associated with that note is narrower in scope than the 200% zoom requirement for 1.4.4.

Can you suggest some changes for that sentence of Understanding which you would find more accurate?

[JAWS-test]

I can suggest changes, but for this there must first be agreement whether at 1.4.10

• 400% has no relevance
• 400% is the main reason and must be fulfilled without exception.
• 400% has some relevance, but does not have to be fulfilled without exception, e.g. not for large text like headings

[patrickhlauke]

noting again that the normative text itself focuses on the viewport dimensions, and not on any zooming / enlarging of content

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

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

Except for parts of the content which require two-dimensional layout for usage or meaning.

So yes, the 400% has no relevance per se. The note explains the reason for those width/height CSS pixel dimensions. The SC does not say "user must be able to enlarge content to 400%".

[bruce-usab]

Agreed, of the three choices, 400% has no relevance is the most correct.