Most nonprofit websites use desktop heading sizes on mobile and hope for the best. The result:

  • titles that take over the whole screen;
  • body text cramped against oversized subheadings;
  • a reading experience that quietly undermines credibility you have spent years building.

It matters more than it sounds. A funder reviewing your site on a train, a trustee checking the annual report summary on their phone, a journalist pulling up your programmes page during a call: all of them see the mobile version. If the headings are unreadable, overlapping or identical to body text, the site looks amateur at exactly the moment credibility matters most.

So mobile heading sizes are not a design preference. They are a governance decision about how you present yourself to the people who fund, regulate and scrutinise your work.

Where The Traffic Actually Is

Most of your visitors are on a phone. M+R's 2026 Benchmarks study puts mobile at 52% of all visits to nonprofit websites, against 48% on desktop. Most boards have never been shown that number.

The figure next to it in the same study is more telling. Mobile accounted for 43% of donation transactions and only 28% of online revenue. Desktop, with less than half the traffic, produced 72% of the money.

Read together, the phone is not a secondary surface. It is the first encounter for most people who look at your organisation, including many who later give, apply, refer or write about you from a desktop.

The mobile site is where the judgement is formed. The desktop site is where it is acted on. So a heading hierarchy that collapses on a phone is not a small cosmetic debt. It is a first impression failing for most of your audience, where you can least afford it.

Why Nonprofit Sites Get This Wrong

Most nonprofit sites are designed desktop-first. An agency or freelancer sets heading sizes to look right on a 1440px screen, then leaves smaller breakpoints to platform defaults or a quick manual override. I see three failures repeatedly.

1. Headings that fill the screen

An H1 set at 48px or larger on desktop, left unchanged on mobile, fills the screen before a visitor sees a line of body text. On a programme page or impact report, it suggests the site was never opened on a phone. Often it was not.

2. Subheadings that look like body text

When H3 and H4 are not deliberately scaled for mobile, they collapse to the same visual weight as paragraphs and the hierarchy disappears. This is the most expensive of the three, because it defeats how people actually read a web page.

Nielsen Norman Group's eye-tracking work describes the layer-cake scanning pattern (Kara Pernice, 2019). Readers fixate on headings and subheadings, and dip into the body only where a heading says it is worth it.

Pages without prominent headings push people into far less effective scanning, where, as the research puts it, they miss meaningful information without any knowledge that they did so. A funder skimming your eligibility criteria on a phone does not know what they failed to find. They simply move on.

3. Sizing that drifts across templates

If heading sizes are set page by page rather than through one scale, every blog post, programme page and resource guide ends up slightly different. The site feels unfinished, not because the content is poor but because the presentation drifts.

The same drift appears wherever templates are edited by hand instead of reading from a shared definition. That is why it tends to sit alongside inconsistent page layouts and unmanaged embedded video on the same sites.

All three are avoidable with one deliberate scale, kept in one place.

The Mobile Heading Scale That Works

A 1.33 ratio, sometimes called a perfect fourth, keeps each heading level distinct on a small screen without any one dominating. The scale below assumes a 16px (1rem) base, the browser default and the sensible starting point for accessible type.

Settle that base alongside the typeface itself, because each constrains the other. A face with a small x-height reads smaller than its stated size, and the scale inherits that at every level.

  • H1: 32px (2rem). The page title, used once per page. Large enough to set the hierarchy without filling the viewport.
  • H2: 24px (1.5rem). Primary section headers, dividing the page into its major blocks. On a programme page these might be "Programmes", "Eligibility" and "Impact and reporting". At 24px they are clearly distinct from the H1 above and the body below.
  • H3: 18px (1.125rem). Subsections within an H2 block, breaking long sections into scannable chunks.
  • H4: 16px (1rem). The same size as body text, distinguished by weight or colour. For minor labels, sidebar headings or metadata categories. If you use colour, it has to clear the contrast threshold on its own, which is a brand and accessibility decision rather than a typographic one.

Two qualifications matter more than the numbers.

These are reference points, not thresholds

WCAG specifies no minimum font size at all, a point WebAIM makes explicitly while noting that size remains a real usability consideration. Anyone who says a pixel value is required for compliance is describing a house style, not the standard.

Heading level is structure, not size

WCAG 1.3.1 Info and Relationships, a Level A criterion, requires that structure conveyed through presentation can be determined programmatically. In practice, the hierarchy has to live in the markup so a screen reader can navigate it, not only as large bold text.

Choosing H3 because H2 "looked too big" breaks the document outline while the page still looks fine. That is why it survives unnoticed for so long. If a page genuinely needs five or six heading levels, rethink the content architecture rather than adding levels.

Line Height, Spacing And Tap Targets

Sizes are half the picture. Spacing decides whether the result reads as composed or cramped.

  • Heading line height. For H1 and H2 on mobile, 1.1 to 1.3 keeps a multi-line title grouped as one unit. Any looser and a two-line heading looks like two separate elements.
  • Heading margins. A heading should sit closer to the paragraph below than to the content above. That proximity tells a reader the heading belongs to what follows. Inconsistent spacing makes the structure ambiguous.

Body text spacing

For body text, 1.5 is the conventional figure, and it is worth being precise about why. WCAG 1.4.12 Text Spacing, at Level AA, does not require you to set a line height of 1.5. It requires that nothing breaks when a reader applies it themselves, along with:

  • paragraph spacing at twice the font size;
  • letter spacing at 0.12 times;
  • word spacing at 0.16 times.

That is a harder test than typing a number into a stylesheet. It asks whether your headings and layout survive being pulled apart by a readability extension or custom stylesheet. Fixed-height heading containers are the usual casualty.

Tap targets

On mobile a heading is often also a control. WCAG 2.5.8 Target Size (Minimum) is new at Level AA in WCAG 2.2, which became a W3C Recommendation on 5 October 2023.

It requires pointer targets of at least 24 by 24 CSS pixels. The exceptions cover inline links within a sentence, spacing, and targets whose size the browser sets rather than you. A collapsed accordion heading, a linked card title or a "read more" under a subheading all fall within it.

Note that 24 by 24 is a floor, not a target. It is where the criterion fails, not where the interface becomes comfortable on a moving train.

What The Standard Actually Requires

Two more criteria are routinely cited here and routinely misstated.

1.4.4 Resize Text

WCAG 1.4.4 Resize Text, Level AA, requires that text other than captions and images of text can be resized without assistive technology up to 200% with no loss of content or function.

The common misstatement is that pixel-based headings fail this outright. They generally do not, because browser zoom scales pixels along with everything else. What pixel values ignore is the reader's default text size: the setting an older donor changes once and expects every site to respect.

A heading in rem inherits that setting. A heading in px overrides it. WebAIM's guidance is consistent on this point, recommending relative units precisely because they give the reader room to adapt the page.

1.4.10 Reflow

WCAG 1.4.10 Reflow, Level AA, requires content to be presented without loss of information or functionality and without scrolling in two dimensions at a width equivalent to 320 CSS pixels for vertical content, or a height equivalent to 256 CSS pixels for horizontal content. Parts that genuinely need a two-dimensional layout, such as maps and data tables, are excepted.

This is the criterion oversized headings fail directly. One long word in a 48px heading on a 320px viewport forces horizontal scrolling across the whole page, not just the heading.

Setting the scale in rem and testing every template at 320px covers both. It is a short list to insist on, and it lasts, which is the point.

Implementing It Without Rebuilding The Site

This is a configuration decision, not a rebuild. On Webflow builds I set the type scale with CSS clamp() and manage the values through Webflow's variables panel. Heading sizes then move smoothly between a set minimum and maximum as the viewport changes, rather than jumping at fixed breakpoints, and the whole scale can be reviewed in one place.

On a CMS-driven site with programme pages, blog posts and a resource library, that single location is the difference between a site that stays coherent and one that assembles itself piecemeal over years of edits.

The mechanism matters less than the principle: one definition, and every template reads from it. No platform gives you a coherent mobile hierarchy by default, and none will stop a future editor overriding one page. What prevents drift is that the values live in one place and somebody is named as responsible for them.

So ask whoever maintains your site where the heading sizes live. It is a one-sentence answer. If they are set on individual elements across dozens of pages, that is a governance finding, not a styling one, and its cost recurs with every new template.

While you have their attention, extend the same test beyond headings. The templates that drift hardest are the ones nobody reads for pleasure, which in practice means donation and enquiry forms. A heading slightly too large costs a reader's patience. A form label collapsed into its own field on a 320px screen costs you the donation.

What This Looks Like In Practice

A deliberate mobile heading scale is visible at once, not as a design flourish but as institutional seriousness.

Consistent, properly scaled headings say someone is paying attention to how the organisation presents itself. An H1 that fills the screen, an H3 that looks like body text and typography that varies by CMS page say the opposite: the website is an afterthought rather than infrastructure.

The audiences that matter most register the difference:

  • institutional funders conducting due diligence;
  • major donors assessing credibility;
  • regulators checking public-facing compliance;
  • journalists researching a story.

They will not call it a typography problem. They will notice whether a site feels professional, and on the evidence above, more than half of them will form that view on a phone.

The Blueprint Audit includes a full mobile experience review in its technical scorecard: heading hierarchy, reflow at 320px, target sizes, and how the site works for the stakeholder groups that matter to you. If nobody has looked closely at your site's mobile experience, that absence is usually itself the finding.