How small can text get before it fails accessibility, regardless of how it looks?

The floor is set by real legibility and resilience to enlargement, not by the smallest pixel size that still renders crisply. Very small text fails because it strains low-vision users no matter how sharp it looks on a high-density screen, so the accessible minimum is a readable size that also survives the user scaling it up. In practice that means body text should sit around 16px, which is the default browser size, and text meaningfully below that starts excluding people regardless of how clean it appears. Accessibility caps how small you can go; aesthetics and density do not get the final say.

The reason crispness is the wrong measure is that retina-grade rendering makes 10px text look perfectly sharp to someone with typical vision, while a low-vision user still cannot read it at all. Sharpness solves blur; it does nothing for the angular size a struggling eye needs. The standards reinforce this with two scaling requirements rather than a single hard pixel minimum. WCAG Success Criterion 1.4.4, Resize Text (Level AA), requires that text be resizable up to 200 percent without loss of content or function, and Success Criterion 1.4.10, Reflow (Level AA), requires that content reflow at a width equivalent to 400 percent zoom (around 320 CSS pixels) without forcing horizontal scrolling. So the real floor is “legible at its base size and still usable when the user doubles or quadruples it,” and a fixed pixel size that ignores the user’s chosen base defeats the first half of that even before zoom enters the picture.

The concrete failure is the fine print: the 11px gray disclaimer in a footer, the 10px metadata timestamp under a card, the tiny caption set small “because it is secondary.” It reads fine to the designer on a sharp laptop and is functionally invisible to the audience most likely to need it. A second, sneakier failure is text that passes by size but breaks under zoom: a navigation bar or pricing table laid out at a fixed pixel width, so that at 200 or 400 percent the words either clip inside their boxes or push the layout into horizontal scrolling. The first fault excludes users at the base size; the second excludes them the moment they try to compensate, and a footer can carry both at once, small and brittle together.

One place the rule bends: this is the accessibility floor, not your type scale. Above the minimum you are free to build hierarchy, with captions smaller than body and headings larger, and the floor only forbids dropping any actual reading text below a legible, scalable size. The one genuine exception is that 1.4.4 explicitly excludes captions on video and images of text, where text is baked into a graphic rather than rendered live; those are governed by other criteria, not by the resize rule. It also pairs size with technique: sizing text in relative units like rem or em lets it honor the user’s chosen base size and zoom cleanly, while hardcoded pixels in rigid layouts are what break under enlargement. Small-but-relative survives; small-but-fixed does not.

Set a real minimum and verify it scales. Keep body text near 16px, refuse to drop any meaningful text into the tiny-fine-print range, and size text in relative units so it respects the user’s settings. Then test by zooming the browser to 200 and 400 percent and confirm the text grows and the layout reflows without clipping or horizontal scrolling, because a size that passes by eye still fails if it cannot be made bigger.