Choose readable website typography and test mobile text, zoom and spacing

Start with representative content instead of a font specimen

Choose a real article with long paragraphs, headings, lists, inline links and a table if the site uses tables. Include a long title and ordinary small text such as a date or source note. A short demonstration paragraph hides the awkward wrapping that readers encounter.

List the text roles before adjusting them: article body, title, section heading, caption, metadata and interface label. Each role needs a clear purpose. Making every line large and bold can remove hierarchy just as effectively as making everything tiny.

For a fictional repair guide, the reader should quickly distinguish the page title, a section called Before you start, numbered instructions and a warning beside a step. The warning’s meaning belongs in its wording and structure, not only a lighter colour or different font.

Record the page and device context for each issue. “The second line of this title overlaps at phone width” is actionable; “the mobile font looks wrong” leaves the maintainer guessing which element, style or condition to change.

Make body text comfortable before refining decoration

Assess the chosen typeface at the size readers actually receive. Letter shapes, x-height, weight, contrast and line length all affect the result. Two fonts using the same CSS size need not look equally large or equally clear.

Use a restrained set of text styles and reliable fallback fonts. Check ordinary bold and italic passages, punctuation and the languages the site publishes. If the preferred web font is unavailable, the fallback should still preserve usable spacing and layout rather than clipping a paragraph or button label.

MDN’s font-size reference explains absolute and relative units, including em and rem. Relative sizing can support a consistent scale, but it does not guarantee readable output by itself. Inspect the resulting size and the layout under enlargement; a relative unit inside a constrained container can still produce a broken page.

Avoid solving an overlong heading by shrinking every article paragraph. Change the relevant text role and check representative pages. Conversely, increasing the body text may require more line height, room for inline controls and adjustments to the content column.

Set a readable measure and coherent paragraph rhythm

Measure is the length of a line of text. A wide desktop container can create lines that are difficult to follow, while an unnecessarily narrow phone column can break words and require excessive scrolling. Adjust the article column and its surrounding padding together.

WAI’s Visual Presentation guidance discusses line width, non-justified text and spacing in a Level AAA criterion for blocks of text. Its numeric conditions are not a universal default design recipe or an automatic Level AA requirement. Use it to understand the reading problem, while testing the site’s own content and audience needs.

Give paragraphs visible separation and a line height that works for the actual font and language. Tight leading can cause collisions in a wrapped heading or text with accents. Excessive leading can make related lines feel disconnected. Review a complete article rather than judging a single line.

A hypothetical guide with a large desktop title may need a more restrained responsive title scale while keeping its body text comfortable. Preserve the title’s identity through weight, spacing and structure rather than assuming it must occupy the same number of lines everywhere.

Use headings for structure as well as appearance

The WAI headings tutorial describes headings that reflect the organisation of the page. Choose levels for the document structure, then style those levels. Do not select a heading level only because its default font looks attractive.

An article title can be followed by main sections and subordinate subsections with meaningful labels. A sentence made visually bold is not automatically a programmatic heading. Equally, a tiny heading still needs to be readable, so semantic structure and visual hierarchy need their own checks.

Keep the distinction between a section title and an ordinary link clear. Check long headings for wrapping, spacing above and below, and separation from the following paragraph. Avoid fixed-height heading containers that assume every title fits on one line.

Check mobile layout without taking away zoom

MDN’s viewport guidance explains how the mobile viewport affects layout and warns against disabling user zoom. If a page initially appears scaled or unexpectedly wide, investigate the viewport and overflowing content instead of blocking enlargement.

Open the actual page on a phone when possible, in portrait and landscape. Check paragraph size, long headings, link wrapping, source notes and the edges of the content column. A desktop device emulator is useful for finding layout issues, but it cannot establish every real-device font or browser behaviour.

Do not confuse an editor’s narrow preview with a separate mobile styling system. Check the scope of the active theme or builder’s control before saving. A change to a shared paragraph style may affect desktop too. If different responsive values are necessary, have the maintainer use the supported theme settings or carefully scoped styles.

Read the page with ordinary browser settings before testing enlargement. If it already requires sideways panning to read paragraphs, investigate a long unbroken string, fixed-width element or excessive minimum width. Reducing all text until the overflow disappears can conceal the actual layout defect.

Test resizing and reflow as separate outcomes

WAI’s Resize Text explanation covers enlarging text to 200% without loss of content or functionality, with the criterion’s stated exceptions. Check that enlarged text remains present and usable; text being visibly larger is only the start of the test.

WAI’s Reflow explanation covers content presentation without two-dimensional scrolling at the specified narrow dimensions, including 320 CSS pixels for vertically scrolling content. A common desktop check uses 400% zoom from a 1280 CSS-pixel-wide viewport. That is a defined testing relationship, not a claim that every browser window starts at that width.

Review these conditions separately. Text-only resizing, page zoom and phone text settings can exercise the layout differently. Inspect clipped paragraphs, overlapping headings, labels hidden by fixed-height containers and sticky interface elements covering the reading area.

Some content genuinely needs a two-dimensional layout, such as certain data tables. The criterion includes exceptions; they do not justify making the entire article scroll horizontally. Check that any necessary table scrolling is contained and that surrounding paragraphs still reflow.

Use WordPress controls at the right scope

For a block theme, WordPress’s Styles documentation describes site-wide and block-level styling. Begin with the shared text roles when the whole publication needs a consistent change; use a block-specific adjustment for a real exception rather than manually restyling every paragraph.

The Typography Settings overview explains controls such as size, appearance, line height and letter spacing, with availability depending on the block and theme. If a control is absent, identify the theme’s supported route before adding a new plugin.

For maintainers, the theme typography reference documents presets and fluid typography configuration. Fluid sizing needs review across narrow and wide widths and under zoom; the label fluid is not an accessibility certificate.

Our first WordPress site guide explains the native-editor approach. A paid page builder is not a prerequisite for a coherent type scale or a useful reading test.

Keep interface labels and contrast in the review

Article metadata, table labels and source notes still need to be legible. The WAI Contrast Minimum explanation distinguishes contrast requirements for ordinary and large text and includes exceptions. Enlarging a muted label does not automatically establish that its actual foreground and background meet the relevant requirement.

Review navigation labels when typography changes, especially wrapping inside mobile controls. Then use the separate mobile and keyboard navigation guide to check operation, focus and submenu behaviour. A readable menu is not proof that somebody can operate it.