Compute sizes so they scale with the text
SCR34 is a sufficient technique for resizing text, qualified for the case of resizing text containers, and W3C files it for reflow as well. The problem it solves is hard-coded arithmetic. A script that decides a menu is 22 pixels per item has fixed the layout to one font size, and the first person who enlarges their text gets every item sliced in half. The method is to ask the browser instead of guessing. W3C names the properties it has in mind, offsetHeight, offsetWidth, offsetLeft and offsetTop, so the numbers your script produces come from what is actually on screen at the size it is actually rendered. There is one test instruction here worth copying word for word. Increase text size to 200% using the browser's text controls, not zoom, and confirm no text is cropped or hidden. Page zoom scales everything together and hides the defect. Text-only enlargement is what exposes it.
How we find it in an audit
We enlarge text to 200% through the browser's own text setting rather than the zoom control, then read the page looking for anything clipped, overlapped or scrolled out of reach. That change of method is the whole test. It is also why scanners do so poorly here. A tool measuring a page at default size sees a layout that works. Our reviewers also read the script itself where we can. A multiplication by a fixed pixel number is a defect waiting for the first person who needs bigger text, whether or not today's content happens to fit.
How affected users experience it
People with low vision enlarge text because it is the difference between reading your page and not reading it. What they get on a page with hard-coded sizes is a menu whose options are cut off halfway down. A button label runs outside its button, and a panel hides its last two lines behind the next section. Nothing is broken enough to look broken. It is just that half the words have gone, and the setting that was supposed to help is the thing that took them.
Passes vs. fails
Passes
menu.style.height = list.scrollHeight + "px";
/* Or let CSS do it, sized in em so the box follows the text: */
.menu { max-height: 12em; }Fails
menu.style.height = items.length * 22 + "px";
// 22 pixels per item, forever. At 200% text each item needs 44.How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Meta viewport allows for zoomA tool can check this
- Zoomed text node is not clipped with CSS overflowA tool finds candidates, you decide
Other ways to satisfy this rule
15 guides on this site are filed under 1.4.4 Resize Text. W3C lists this one as sufficient for that rule when used for techniques for text container resizing, so the condition is part of the test rather than a footnote to it.
- C12sufficientSize text in percent so it scales
- C13sufficientUse named font sizes that respect user defaults
- C14sufficientSize text in em units, not pixels
- C28sufficientSize text containers in em units
- G142sufficientBuild with technologies whose browsers support zoom
- G146sufficientUse liquid layouts that fit any window
This guide is our interpretation of W3C technique SCR34: Calculating size and position in a way that scales with text size. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.