DSG-02

High number of distinct font sizes

InfoAccessibility

What the check measures

Visible elements with their own text are walked and distinct font sizes counted (rounded to whole pixels). The finding is raised when there are more than 8 (config/design.json#thresholds.maxDistinctSizes, a value marked PROPOSAL).

Only elements with their own direct text count, not wrapping containers. The page is walked up to a maxNodes limit; a very long page is therefore only partly counted.

What the check does not do: it does not judge whether those sizes form a sensible scale (8 sizes in a geometric progression is better design than 5 arbitrary ones), it does not separate sizes from different sections, and it cannot tell that two sizes differ by a single pixel. To it they are two.

The finding is page-level and informational. It costs no score at all.

How strong the evidence is

Effect not demonstrated

We recommend it because it does no harm or has some other benefit, but we promise nothing about whether it makes language models cite you. Nobody has demonstrated that yet.

For visibility in AI answers there is no effect at all, and none for ranking either. This is a finding about visual consistency: about craft, not about a measurable outcome.

We will be more candid here than elsewhere: the number 8 is our convention, not a standard. No specification says how many font sizes are correct. It is an observation from practice: a typographic scale usually gets by on six to eight steps, and more tends to indicate that sizes were created one at a time as needed, rather than designed.

What that means practically: a high number is not a defect in itself. It is an indication that styles accumulated from different eras or different people. And that has consequences for maintenance, not for visitors. A site with twenty font sizes is harder to change and easier to break.

When to ignore it happily: when your site has a designed scale and it has nine steps. That is why the finding is informational and costs no score. We expect you to override it sometimes.

How to fix it

This is tidying, not repair, and it pays off only when you are going to touch the styles anyway. A process that works:

  1. List what is actually on the page. The browser console does it in a second (below).
  2. Choose a scale of six to eight steps and name it with CSS variables.
  3. Map every existing size to the nearest step. A difference of a pixel or two goes unnoticed.
  4. Take new sizes only from the scale. Without that it returns within a year.
const sizes = new Set();
document.querySelectorAll('*').forEach(el => {
  const hasOwnText = [...el.childNodes].some(n => n.nodeType === 3 && n.textContent.trim());
  if (hasOwnText) sizes.add(Math.round(parseFloat(getComputedStyle(el).fontSize)));
});
console.log([...sizes].sort((a, b) => a - b));
:root {
  --text-xs: 0.8125rem;
  --text-sm: 0.875rem;
  --text-md: 1rem;
  --text-lg: 1.125rem;
  --text-xl: 1.5rem;
  --text-2xl: 2rem;
}

One more thing worth doing at the same time: use rem, not px. Pixel sizes ignore the browser's font-size setting, so somebody who enlarged text because of their eyesight will not get it enlarged on your site.

What the report says about it

Finding description

On the checked page we counted [distinctSizes] distinct font sizes, above the reference threshold of [threshold]. This is NOT an accessibility fault nor a proven effect on AI-search visibility. It's just a signal about typographic consistency.

Recommendation

Consider limiting font sizes to a smaller set of levels from a design system (headings, labels, body text). A more consistent type scale tends to read more clearly, though that alone guarantees nothing.

Sources

Text verified 2026-09-12