← All postsFont Basics

Accessible Typography: Contrast, Resizing, Reflow and User Spacing

Separate WCAG AA requirements from design preferences, then check whether real text survives zoom, narrow layouts and spacing overrides.

Start with requirements, not font folklore

Accessible typography is not a single typeface or a mandatory default body size. It is a set of decisions that let people perceive, enlarge and use text without losing information. A familiar sans serif cannot compensate for faint labels, clipped instructions or a layout that breaks when text grows. Equally, a serif is not automatically inaccessible. Evaluate the actual content, styling and behaviour rather than assigning accessibility to a font category.

WCAG provides testable requirements, while design recommendations help you choose a comfortable starting point. Keep those categories separate. A body size of 16px or 18px may be a sensible design choice, but WCAG AA does not establish a universal 16px minimum for all text. A line length recommendation can improve reading comfort without being an AA requirement. Clear documentation should identify which decisions are compliance obligations and which are your product’s editorial preferences.

Apply the correct contrast threshold

Under WCAG’s Contrast (Minimum) criterion, ordinary text and images of text generally need a contrast ratio of at least 4.5:1 at Level AA. Large-scale text generally needs at least 3:1. Large-scale means at least 18pt regular or 14pt bold, approximately 24 CSS pixels or 18.67 CSS pixels respectively. Those are size and weight conditions, not a licence to classify any prominent-looking heading as large.

For example, a 20px regular-weight section heading does not qualify for the large-text threshold simply because it is bigger than the body copy. A 24px regular heading generally reaches the size condition. A 19px bold heading may reach the bold size condition, but a very thin or unusual face still deserves care. When uncertain, meeting 4.5:1 is a more robust design target than trying to justify a marginal classification.

Measure the actual foreground and background combination, including relevant states and placements. Grey helper text, placeholder text and text inside controls need attention; looking secondary does not make information decorative. A heading on a photograph needs a sufficiently contrasting background wherever the letters appear. A scrim or solid panel can be more dependable than hoping that one crop remains unchanged across screen sizes and future content updates.

Do not round a failing ratio upward. A computed result of 4.499:1 does not meet 4.5:1. Also distinguish the criterion’s exceptions from general permission to use faint text. Logotypes, genuinely incidental text and inactive interface components receive specific treatment, but an essential instruction is not incidental because the design makes it small. Contrast testing is a threshold check, not a substitute for reviewing clarity and reading comfort.

Make enlargement preserve the task

The WCAG 2.2 standard includes Resize Text, success criterion 1.4.4. Except for captions and images of text, text must be resizable without assistive technology up to 200% without losing content or functionality. The practical question is not merely whether the browser’s zoom control works. It is whether the page remains usable after enlargement: can someone still read the instructions, reach controls and complete the same task?

A button with a fixed height can fail this practical check when its two-line label is clipped. A navigation item may disappear beneath an adjacent control. A price may overlap its currency or billing period. Review these cases with real content, including longer labels. Relative sizing and flexible containers can help, but no unit automatically guarantees success. A layout using rem units can still break if its boxes cannot grow.

Avoid counteracting zoom by shrinking text aggressively at responsive breakpoints. Adaptation is useful, but the user’s attempt to enlarge content should remain effective. Test representative pages rather than only the homepage. Forms, checkout summaries, search filters and account settings often contain tighter constraints than editorial pages. Record the viewport, browser and zoom settings used so that somebody else can reproduce any failure and verify the correction.

Check reflow separately from resizing

Reflow, success criterion 1.4.10, addresses a related but different problem. For vertically scrolling content, information and functionality must generally remain available at a width equivalent to 320 CSS pixels without requiring scrolling in two dimensions. For horizontally scrolling content, the corresponding height is 256 CSS pixels. The criterion includes an exception for content that genuinely requires a two-dimensional layout for its usage or meaning.

For a typical article or form, check a 320 CSS pixel-wide layout and inspect every component, not just the body column. Long links, unbroken identifiers, wide inputs and sticky toolbars can introduce horizontal overflow. Tables, maps and other genuinely two-dimensional content need considered handling, but their presence does not excuse an entire page from reflowing. Keep ordinary surrounding instructions and controls usable without unnecessary side-to-side scrolling.

A common desktop check uses a 1280 CSS pixel-wide viewport at 400% browser zoom, producing an effective width of 320 CSS pixels. That is a useful scenario rather than the only possible test configuration. Resize Text and Reflow remain distinct requirements: passing one does not establish the other. A page can allow large text while forcing horizontal reading, or fit a narrow width while preventing sufficient text enlargement.

Support spacing overrides, not mandatory default spacing

The Text Spacing criterion, success criterion 1.4.12, requires no loss of content or functionality when users override specified spacing properties together. The values are line height of at least 1.5 times the font size, spacing after paragraphs of at least twice the font size, letter spacing of at least 0.12 times the font size, and word spacing of at least 0.16 times the font size.

These are not required default styles. W3C explicitly states that content is not required to use those values. The requirement is to tolerate the override without losing information or functionality. A compact display heading can therefore have a tighter authored line-height, provided user spacing changes do not cause clipping, overlap or inaccessible controls. Exceptions account for languages and scripts that do not use one or more of the specified properties.

Use a test stylesheet or suitable browser tool to apply all four overrides without changing unrelated styles. Then inspect labels, tabs, cards, dialogs and error messages. Fixed-height components and hidden overflow deserve special attention. A paragraph becoming taller is expected; its final sentence disappearing is not. Do not “fix” the test by disabling user styles or restoring the original spacing through more forceful CSS.

Choose fonts within a resilient layout

When comparing families in the free font catalogue, inspect ambiguous characters, punctuation, numerals and the scripts your audience needs. Compare ordinary reading text rather than only headings. Choose weights that remain clear on the intended background and avoid making essential instructions depend on a delicate style. These are practical selection checks, not a claim that one family guarantees accessibility for every reader.

Finish with a repeatable review covering contrast, 200% resizing, narrow reflow and simultaneous spacing overrides. Add keyboard and assistive-technology checks to the wider accessibility process; typography alone cannot establish full WCAG conformance. Record failures as specific behaviours, such as “error text clips after spacing override,” rather than vague judgements about readability. That turns accessibility from a font-selection opinion into maintainable work on the actual experience.

Further reads

Six more posts to dig into next.