WCAG SC 1.4.4 Resize Text & 1.4.10 Reflow

There seems to be a confusion about the relationship and how to test for the WCAG 2.1 Success Criteria 1.4.4 Resize Text and 1.4.10 Reflow.

While these two success criteria seem related, they cover different use cases.

1.4.4 Resize Text

This success criterion that was introduced with WCAG 2.0 on level AA covers text resizing without assistive technologies. The requirement is that, except for captions and images of text, text can be resized up to 200% without losing content or functionality.

Note how the success criterion does not specify a specific method to reach this state of two times the font size. As long as the way to resize the text is “accessibility supported”, it is a valid way to conform to WCAG:

Resizing only the text (classic text resizing)
Zooming the page using browser features (viewport resizing)
Changing the viewport by changing the display resolution
Providing an on-page text size picker

Of course some ways are better than others and adjusting the viewport to resize text is frequently the most consistent way to do it, especially on websites that have been implemented in a responsive way.

That said, this SC is relatively permissive. As long as the text does not get completely lost (for example through overflow: hidden or text running into each other or behind other objects), your layout is allowed to break. And, more importantly, this success criterion gives no guidance on scrolling. It totally conforms if your website grows to twice the width and height when resizing the text to 200%, even if that means horizontal scrolling.

1.4.10 Reflow

Reflow was introduced to support users with low vision to easier navigate zoomed-in experiences by giving them a viewport size that – guaranteed – would not scroll horizontally. Reflow has nothing to do with resizing the size of the text at all.

It specifies that the content can be presented in a way that only requires scrolling in one direction at 320px for content that scrolls vertically (up and down) and 256px for content that scrolls horizontally (left and right).

There is an exception for content that requires two-dimensionality to be understood, example tables, maps, or some charts.

The reason for picking 320px/256px have been of practical nature. Firstly, 320px is a very common viewport width for smartphones. Secondly, if you use a desktop browser on a 1280px wide monitor and zoom in to 400% the width of the viewport is quartered internally in the browser… to 320px.

Using browser zoom on a desktop browser is functionally equivalent with changing the width of the viewport. Zoom to 200%, your viewport width halves.

How do these two success criteria work together?

From a desktop view, if you meet Reflow, you almost certainly also meet Resize Text. Even if your media query uses a lower font size for mobile devices, it would need to be very small to fall under the 200% threshold.

If your base font size is 16px, 200% is 32px (and note that these are real on-screen pixels, not CSS pixels dependent on your viewport here). A 8px size font in the 320px view would still meet the requirement of Resize Text. And Reflow has no requirement that the resulting text size needs to be at a certain size.

That said, once you are on a mobile viewport, you still need to be able to resize to 200% without losing any information (but scrolling horizontally is then allowed).

So… how is this supposed to be tested?

Resize the viewport width to 320px by 256px. Scrolling of the web page needs to happen in only one direction at a time. It is allowed to have sections of the page scroll into the other direction, but it must stay inside the viewport. For example would it be permissible to have a horizontal card area on an otherwise vertically scrolling page, but only if all information is visible in the viewport without being required to scroll in two dimensions.

Bump up the text size to 200%. You can do that through further zooming to a 160px viewport or resizing only the text. Important is that the resulting font size is 200% of the font visible on screen. (Note that the SC does not require that the text resize matches the setting. As long as you can eventually get to 200%, it is permissible, even if that means using the browser setting to 300% because a media query is using a smaller font size in the middle.)

In practice

Practically speaking, these success criteria are usually unproblematic, especially for modern, responsive websites. Yes, mistakes happen, and sometimes there is content that gets removed on smaller viewports. Or some CSS goes wrong when actual, real content meets it.

It can be tricky in complex web applications, especially if no mobile version exists or the mobile version removes content/functionality, as that is not allowed.

That said, text resizing in browsers is well supported (remember when Internet Explorer refused to resize text specified in pixels?) and the profileration of CSS Grid and Flexbox techniques for layouts makes it often less likely to break, compared to the float-based layouts back in the days. And web developers have learned to adapt better to different viewport sizes over the decade of responsive web development, which has brought a huge increase in accessibility in that area.