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.
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.)
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.
More content like this?
Support me on Steady and get blog posts like this in return!
Comments & Webmentions
My phone has four text size settings and then Chrome lets me scale the text up to 200% of that. Lots of web pages start to break when I max the text size. It seems like testing classical text zoom only is at least as important as testing page zoom, if not more.
But that means that the text is resized to more than 200% of the specified base, which is not covered by WCAG, even if you test text zoom.
200% of the specified base
What is the specified base? I can set my default text size as big as I like on my desktop browser. I know from experience that setting it to 32px, or even just 24px will break a lot of web pages. Is WCAG assuming that the 200% is based on the default 16px font size that most browsers ship with?
WCAG requires to test that it’s possible to increase the size to 200%. That means that text on the page can be at least twice the size as specified in the CSS. WCAG does not cover cases where the font size is larger than 200%, even if you can do that in your browser.
That means that text on the page can be at least twice the size as specified in the CSS
But what if I'm not specifying the text size in CSS? If the user has their default font size set to 32px then does that mean the page must be able to handle up to 64px in order to meet 1.4.4?
I’m not sure if you’re trolling. 200% from the default as specified by the website. If you have already changed the base font size from the browser-defined 16px, the website does conform if there is no loss of information as your font size has increased to 200%. At the point where all text on the page is 200% from the view without any changes, the SC is met.
I'm sorry if I come off as trolling because I am not in any way. I have always thought there was a weakness in WCAG 1.4.4 because it doesn't clearly define what 200% is based on. I never specify a font size in px for my pages, I always respect the user's default font size setting and only use rem units. Thus, if the user has their default font size set to 32px then that is the default font size specified by my website. You could only consider that being zoomed 200% if you consider 16px to be the de facto universal default, but I don't recall seeing a default font size in WCAG 1.4.4. Perhaps I am wrong and you are trying to tell me that 16px is what 200% is based on? If so, I think it needs to be made clearer in the SC.
I hope I am being clear enough and it doesn't look like I'm trolling.
It does not matter if you set a font size or not. Without any user setting, the font size is X, based on the 16px and the default font sizes specified in the browser’s stylesheet. Any text on the page needs to be able to scale to at least 200% from that default view. How that happens, if it is through the user’s default font setting or text resizing or zooming, does not matter for WCAG SC 1.4.4.
Nice explanation! However, it is a little ironic that the title on your blog post doesn’t meet reflow on my mobile screen then. 😉
I removed the non-breaking space. I don’t like that it breaks in the middle of the SC name on desktop now, too, but what can you do? 😂
And yes, I know that the situations with the nested comments below the article is… not good. I hope to fix it soon.
In the guidelines themselves 1.4.4 is "up to" 200% and 1.4.10 only specifies the single breakpoint, but the Understanding section refers to "the goal of allowing people to zoom in to 400%" - so for older websites, I usually recommend that testers use the 1280 x1024 method and zoom in steps from 100% and 400%, as content can fail to reflow e.g. at 250% and be fine again at 400%. This is not rare on the sites we're reviewing. That means treating the intent of "to 400%" as "up to 400%" so a strict reading might ignore those intermediate zooms depending on how much weight you give that lack of the word "up"
(Another note from testing this - if you use the 320 method, this IS rare but some old, not properly responsibe websites are using device detection, so don't use or simulate an actual mobile phone for those, as you may get different results than in the browser window at the same width)
That said, text resizing in browsers is well supported (remember when Internet Explorer refused to resize text specified in pixels?)
Except it's not. If you set your text size in pixels, it will not budge when browser font size settings are changed. I mark this as a failure when doing accessibility audits. Yes people can use zoom, but those who prefer to set a default browser font size are left out.
If you use the text resize functionality in browsers, pixel sizes will resize. Setting a base pixel size will not, as author styles overwrite user agent styles. Still, if it is possible to resize the text to 200% using any method, it cannot be a failure of 1.4.4.
Hi Eric. What is your motivation for choosing 320 pixels as the starting width before zooming? Am I free choose any other starting width that I prefer to evaluate my website, such as 1280, 1024, 800, or 160?
My assumption is that if you can reflow to 320px, at 100% text size and then can resize the text to 200%, you have the best out of both worlds. It’s also most likely that things get cut off at mobile sizes.
Great article Eric, this clarifies a lot of questions that I've had. For my own understanding, I'd like to see if I can summarize to make sure I'm hearing the differences right, so I'm not accidentally misusing the criteria. Others are welcome to correct if I'm misreading something:
Text resize: increase text to 200% of base font size (set by user agent and/or theme default, depending). This can be done using techniques mentioned. Scrolling or layout break is allowed, because all that matters here is the ability to resize text. Text should not be overlapped/hidden/lost.
Reflow: At 320px width, content (interpreting as including text/parts of text) must be presentable without needing horizontal scroll, so it only scrolls vertically. At 256px height, the same is true but for vertical scroll. 2-dimensional scrolling here is definitely not allowed--make sure content isn't lost/hidden on reflow.