I also twinged on this yesterday when opening a separate change to existing language for Reflow. I agree it needs some wordsmithing.

Is this clearer?

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would mean a text size of 200%. At 400% zoom, the author may decide to set the text size to 10px: the text would now still be enlarged to 200% compared to the default browser setting of 100% zoom. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

I had some misgivings about "in some way", and maybe we can still find a better formulation.

Am I correct in assuming that an author offering reflow but constantly reducing text size when moving to narrower breakpoints (always remaining below 200%) would still meet 1.4.4 if he/she offered a style switcher serving another style meeting the 200% requirement?

Hi Wayne,
it is not clear to me why you think 1.4.10 Reflow would not pass when text size is progressively reduced. It is my understanding that Reflow checks single column layout at 320px viewport width, not the text size at that breakpoint. 1.4.4 would instead check whether zoom will reach 200% text magnification at some point OR whether there are alternative means of enlarging text to 200%. Having said that, in most cases 1.4.4 will be met by allowing users to zoom in from default to 200% and not reducing text size at the resulting breakpoint.

Am I correct in assuming that an author offering reflow but constantly reducing text size when moving to narrower breakpoints (always remaining below 200%) would still meet 1.4.4 if he/she offered a style switcher serving another style meeting the 200% requirement?

I would say yes. as having a switcher/configuration options/etc would allow for the text to "be resized without assistive technology up to 200 percent"

as an aside, an example of a technique passing 1.4.10 but failing 1.4.4 would be a responsive site that sets its font size using purely vh or vw units. A user would be able to zoom to 400% or even further, changing the effective CSS pixel dimensions of the viewport, and - assuming the layout adapts to it - getting to 320 CSS px without causing horizontal scrolling...but having the effective text size never actually change.

(random link to an unrolled thread view of a series of tweets i did about this ages ago https://threadreaderapp.com/thread/927508868686639105.html )

extrapolating a bit from what i think wayne may be trying to get at, let's imagine a site that does allow zooming up to 400% and reflows correctly, but that (due to font sizing shenanigans) even once you zoom to 400%, you've NOT managed to increase the font size to 200%. to actually reach 200%, you end up having to zoom even further (though most browsers don't let you zoom much further 500%, but let's assume for argument's sake). and say that THEN, once you've managed to get to 200% font size, reflow doesn't occur and scrollbars do happen. i'd say there that the site PASSES 1.4.10 (as zooming until the viewport is only 320 CSS px width was indeed possible), AND it PASSES 1.4.4 (as it was possible to increase text size to 200%).

If, at that much higher zoom ratio (and much smaller viewport size in CSS px), once 200% text size was finally reached, the layout starts to break apart though (things overlapping / getting cut off, etc), then it still PASSES 1.4.10, but then FAILS 1.4.4 (as there's a loss of content/functionality).

Wayne I understand where you're coming from, but: that's not now in the normative text. Coupling these SCs together in this way would be a substantive change, which can't be done just through adding some bits to the understanding docs.

Detlev’s update looks fine to me, if people find that clearer.

@WayneEDick we’ve been around this a couple of times - if we require text to get to 400% larger, that would also capture times when it is unhelpful to do so. The only (relatively) common instance of shrinking text in a major way is for headings that are very large to start with. Making a heading 4 screens high doesn’t really help anyone.

In general (as we discussed) people don’t reduce the body-text size at higher zoom / smaller screens because it would be unreadable to most people.

@patrickhlauke - we have a failure for using viewport units to restrict text size.

Proposed working group response:
We suggest to change the text as follows (compare #702)

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would mean a text size of 200%. At 400% zoom, the author may decide to set the text size to 10px: the text would now still be enlarged to 200% compared to the default browser setting of 100% zoom. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

The PR got merged, and I think there's another PR on the same topic and section of the document which will go into the survey this week.

It might be helpful to mention zooming sets a scale factoe otherwise ira confusing.

yeah...the tl;dr is really:

• 20px at 100%
• user bumps zoom to 200%, it now is still 20px, but scaled x2, so APPEARS 200% in size (appears visually as 40px)
• if the author now has some media query or whatever that at kicks in when zooming to 400% (because it changes the viewport width and triggers some "smaller screen" styles) and sets the base size to 10px, the end result is 10 CSS px scaled x4, so still appears as 40px size

Ok so how about this?

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would show an apparent text size of 40px. At 400% zoom, the author may decide to set the text size to 10px and the text would still be enlarged to an apparent 40px. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

Also noting there is another PR (#715) for the paragraph above, and another issue (#704) about the concept of starting points for reflow.

Ok so how about this?

Yup, I think that now makes it even clearer.

I agree with Patrick, but the last sentence of @alastc proposal has me scratching my head.

It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

Don't we have to be able to get 200% (of the base value) at any breakpoint. Am I missing something? If so, I assume others less familiar with the subject will be more confused. How about something like this ...

It should be possible to get 200% text enlargement of the default text size at each break point. The author may reduce the font size at narrower breakpoints if doing so still allows a 200% zoom over the default text size at 1280px, although it is recommended not to reduce the font size at narrow breakpoints.

Depending on breakpoints, you may already end up jumping to an adjacent breakpoint before you zoomed the content to 200%...so it's impossible to say that at each breakpoint users must be able to get to the 200% text size. But what it means is that from their starting zoom, they must be able to eventually reach a state/breakpoint where the text is indeed 200% the original size (regardless of whether they're still in the same breakpoint, or if their zooming resulted in triggering another breakpoint)

e.g. a site may have breakpoints at "anything greater than 1280 width", "1024 - 1280 width", "800 - 1024 width", "400 - 800 width", "anything below 400" (or some similar granular arrangement). For most starting widths, you can't zoom to 200% without sliding into another breakpoint, so you'd never be able to say that for each breakpoint (and without triggering another breakpoint) users must be able to get 200% text size. now, whether developers change the actual base font size or not for each breakpoint is another matter...it's not a given, and beyond some minor tweaks, it's rarely done. If we feel it's common, we can probably address this, but with a separate note (rather than overloading this text further)?