But what does this exactly mean?

When I started to study this question intently, I found out that there is no solution at the time as well as detailed explanation. The great recommendation is:

So, if you want to be sure that the user will be able to zoom in the text to at least 200% of original size, you should make a huge amount of tests. In this article I propose the solution how to predict the mentioned WCAG Failure at the stage of development. And I am not sure that my findings will guarantee the 100% absence of the problem, but I am sure that it will be helpful to avoid developers from rough errors in the real use cases.

So, what is really going on when users try to zoom the web page? The answer to this question is very simple: All modern browsers assume that pixel is stretchable. Therefore, the screen size “effectively” decreases on zooming.

When we try to zoom the page to 200% of its original size, the pixel becomes twice as large in height and width. So, look at the code below:

Without zooming, we will see a text of this paragraph as text of some “visual-size”. Due to different physical size of pixels for different devices, this “visual-size” will change from one device to another. Really, if your 42-inch TV has a resolution of 1920×1080 pixels, then it contains 2073600 pixels, and your 6.1-inch iPhone 13, for example, has a resolution of 2532×1170 pixels and contains a whopping 2962440 pixels. Let introduce some coefficient k that is proportional coefficient between “visual-size” (what we see on screen) and “font-size” (what we set in CSS):

This coefficient depends on type of screen. But as we will see below, it does not effect on a final result.

Now let’s try zoom in and see what happens.

As we can see, the `"visual-siz"e` of the text monotonically increases while zooming, and we can describe this by introducing the `"zoom-coefficient"` (browser zoom) as the following:

The `"zoom-coefficient"` is equal to 1 for the original size (without zoom in), 2 — for 200% of browser zoom, 3 — for 300%, and so on, and `"zoom-coefficient"` < 1 when we zoom out. Now we can introduce and calculate a `"visible-zoom"` coefficient, which is a measure of the real visible increasing (decreasing) of a size of the text, as ratio:

\$\$begin{eqnarray} (3)quad visible_zoom&=&frac{textrm{size what we see while zooming},(zoom_coefficientne 1)}{textrm{size what we see without zooming},(zoom_coefficient=1)}=nonumber \ \ &=&frac{(k zoom_coefficient font_size)}{(k * font_size)}=zoom_coefficient nonumber end{eqnarray}\$\$

As we can see from equation (3), the `"visible-zoom"` is equal to browser `"zoom-coefficient"`. That is, to double the text size (`"visible-size"` of text), we need to simple apply browser 200% zoom in. So, the mentioned WCAG Failure Under 1.4.4 Resize Text (AA) will never be observed in the case of not responsive typography (constant font size).

It is an example of fluid (responsive) typography. Fluid typography give us the possibility to change text smoothly with viewport width. The widespread implementation of such concept in CSS stylesheet is to use a `clamp` function. Using `clamp` you can smoothly change `"font-size"` between `"min-value"` and `"max-value"` in the given range of viewport width (from `"start-width"` to `"end-width"`).

In such the case, when font-size value depends on viewport width, equations (2) and (3) can be easily modified. In these equations we should take into account two facts:

The second fact is not so obvious like the first one. But we should remember that under zooming the viewport width “effectively” decreases. So, we will have the following transformation when zooming:

Using relation (4), equation (3) take the following form:

\$\$begin{eqnarray} (5)quad visible_zoom&=&frac{k zoom_coefficient font_sizeleft(frac{viewport_width}{zoom_coefficient}right)}{k font_sizeleft(frac{viewport_width}{zoom_coefficient=1}right)}=nonumber \ \ \ &=&frac{zoom_coefficient font_sizeleft(frac{viewport_width}{zoom_coefficient}right)}{font_sizeleft(viewport_widthright)} nonumber end{eqnarray}\$\$

Equation (5) and a simple criterion (“minimum 200% zoom requirement”):

can be used to check whatever users can get text to 200% of its original size for the available range of browser zoom (up to 5 or 500% nowadays) for the any value of viewport width. On a practice, it is better to create some 3D plot in coordinates `"visible-zoom"``"viewport-width"``"zoom-coefficient"` or corresponding contour map. Such visualization is an easy way to estimate the extent of the problem if it exists.

From these equations one can find that `"start-width"= 22.5rem= 360px`, and `"end-width" = 52.5rem=840px`, or represent the result graphically:

\$\$begin{eqnarray} (7)&quad& font_size(viewport_width)=nonumber\[5pt] &=&left{begin{array}{cc} function_1 (viewport_width),,viewport_width>breakPoint_1,nonumber\[3pt] function_2 (viewport_width),,breakPoint_1>viewport_width>breakPoint_2,nonumber end{array}right. end{eqnarray}\$\$

\$\$begin{eqnarray} &quad& font_sizeleft(frac{viewport_width}{zoom_coefficient}right)=nonumber\[5pt] &=&left{begin{array}{cc} function_1left(frac{viewport_width}{zoom_coefficient}right),,frac{viewport_width}{zoom_coefficient}>breakPoint_1,nonumber\[3pt] function_2left(frac{viewport_width}{zoom_coefficient}right),,breakPoint_1>frac{viewport_width}{zoom_coefficient}>breakPoint_2,nonumber end{array}right. end{eqnarray}\$\$

It is your choice how to use equation (5), but I recommend to reduce the task to pt. 1/2(i).

It should be noted that we did not consider operating system zoom here. When user applied it this will also affect on “effective” screen size. As a result, the `"zoom-coefficient"` should be represented as a product of browser and operating system zoom. Such influence on final prediction will be similar to the case of changing browser default font size.

Now we are able to predict the behavior of text size changing while zooming to avoid the WCAG Failure Under 1.4.4 Resize Text (AA). Equation (5) and “minimum 200% zoom requirement” (6) give us an easy way to anticipate a problem on the stage of development and analyze it. Due to a variety of possible dependencies for a text font size on viewport width that developer can implement, there is no general solution of a problem. But you can slightly change the input parameters and view the predictions. In most cases, such corrections will give the desired result. We should make a choice in favor of completely eliminating possible problems with text scaling.

source