Text that looks fine at full design size can shrink to unreadable once squeezed into a dashboard card

What it is

A 14-px axis label is crisp on a 2,000-px design canvas, but once the chart is shrunk into a 300-px dashboard card or printed at half a column on A4, the same text is a few physical pixels tall—unreadable. Text readability is set by the physical rendered size (actual height on the final medium), and charts get scaled throughout their lives (responsive layouts, screenshots, projection, print); the design-file size is merely the largest rendering they will ever enjoy. The size standard must therefore be validated against the smallest real usage scenario.

Why it happens

The rendered-size mechanism stems from how chart text scales differently from page text: HTML text reflows with layout and zoom, but charts are often scaled as a whole (SVG scaling, bitmap scaling, canvas scaling), so their internal text shrinks proportionally without reflowing—the design file's "big enough" holds on the big screen, while the shrunk chart's text is the proportional-scaling victim. Physical readability thresholds include: a discernible minimum character height (roughly an effective 9-12 px, with low-vision users needing 2-3x), and viewing-angle requirements under projection (back-row audience may see one quarter of the designer's visual angle). The practical rule: register each chart's "minimum usage width" (the smallest container it will live in), verify every text element's effective rendered size at that width—axis and data labels no lower than an effective 11-12 px—and when labels become unreadable after scaling, switch to hover or selective annotation of key points instead of shrinking everything. Vector formats (SVG) preserve clarity under scaling but not size—"vector" solves sharpness, not smallness.

Where it stops holding

Font size trades off with information volume: full data labeling often conflicts with minimum size (too many points to label), and the remedy is annotation layering (key points labeled, the rest on hover) rather than global font shrinking. Fixed-physical-size contexts (print reports, conference posters) allow exact validation (font size converted to millimeters), while responsive contexts must validate at every breakpoint. Another boundary is the user's right to zoom: chart text rendered as real text (SVG text, HTML) grows when the user zooms the browser—bitmap text (exported PNGs) has no such ability, one of the accessibility reasons interactive pages should prefer vector rendering.

Applying it

• Register each chart's "minimum usage width" and verify every text element's effective rendered size at that width (inspect via dev tools).
• Axis and data labels must not fall below an effective 11 px in the smallest scenario; otherwise move them to hover/selective annotation instead of shrinking the font.
• Preview readability at the target size before screenshotting, exporting, or embedding into other documents.
• Verification: place the chart in its smallest real container (card, half-screen) and read the axis labels; if you must squint or zoom, it fails.

Related

• Same group: U11.04.1 Chart marks need discernible contrast against the background · U11.04.2 Mark-vs-background contrast and adjacent-category contrast are two independent requirements · U11.04.3 Too-thin lines vanish on low-contrast screens and projectors · U11.04.5 Interactive marks are also bounded by touch-target requirements
• Nearby: U11.04.3 Too-thin lines vanish on low-contrast screens and projectors · U7.06.5 The active time range must be visible alongside the chart
• Search terms: minimum font size · rendered size · responsive chart