Typography for interfaces

A MealBox help article set in 14 px type at a line height of 1.2 runs about 174 characters to a line on a 1280 px screen, more than twice the 80 characters that WCAG 2.2 sets at its highest conformance level. The screen, article and widths in this lesson are invented.

Typography is most of an interface, because most of an interface is text. You will choose sizes from a type scale, set the length and height of lines, and then test the result where designs break: when a visitor enlarges the text, restyles its spacing or reads it in Hindi. All three tests use numbers you can compute.

A type scale gives every level a size you can defend

A type scaletype scale: A short list of text sizes in a fixed ratio, for example each step 1.2 times the one before, from which every size in a design is taken. is a short list of sizes in a fixed ratio, so that each level of text is a clear step from the next. This lesson’s scale starts from the 16 px body size and multiplies by 1.2 at each step, a ratio chosen for this lesson. Start from the platform’s own default: MDN documents that a browser’s default font size is usually 16 px, and Apple’s guidance lists 17 pt as the default and 11 pt as the minimum on iOS and iPadOS.

The program prints the seven steps in px and rem, the unit that follows the visitor’s own default size, and checks that rounding to whole pixels keeps the ratio:

# A type scale for MealBox articles: each step is 1.2 times the one before, starting from the 16 px body size.
BASE_PX = 16
RATIO = 1.2
STEPS = [(-1, "caption"), (0, "body"), (1, "small heading"), (2, "heading"), (3, "large heading"), (4, "page title"), (5, "display")]

print(f"ratio {RATIO}, base {BASE_PX} px = 1 rem")
print(f"{'step':>4}  {'role':14}{'px':>7}{'rem':>8}  {'rounded px':>10}")
for step, role in STEPS:
    px = BASE_PX * RATIO ** step
    print(f"{step:>4}  {role:14}{px:>7.2f}{px / BASE_PX:>8.3f}  {round(px):>10}")

sizes = [BASE_PX * RATIO ** s for s, _ in STEPS]
gaps = [b / a for a, b in zip(sizes, sizes[1:])]
print("\nratio between neighbours:", ", ".join(f"{g:.2f}" for g in gaps))
rounded = [round(s) for s in sizes]
print("neighbour ratios after rounding to whole px:", ", ".join(f"{b / a:.2f}" for a, b in zip(rounded, rounded[1:])))

ratio 1.2, base 16 px = 1 rem
step  role               px     rem  rounded px
  -1  caption         13.33   0.833          13
   0  body            16.00   1.000          16
   1  small heading   19.20   1.200          19
   2  heading         23.04   1.440          23
   3  large heading   27.65   1.728          28
   4  page title      33.18   2.074          33
   5  display         39.81   2.488          40

ratio between neighbours: 1.20, 1.20, 1.20, 1.20, 1.20, 1.20
neighbour ratios after rounding to whole px: 1.23, 1.19, 1.21, 1.22, 1.18, 1.21

The page title lands at 33.18 px and the display size at 39.81 px. Rounded to whole pixels the neighbouring ratios wander between 1.18 and 1.23, which is why a scale is stored as numbers, not rounded by eye. Use three or four steps on one screen and let weight and colour do the rest, as the previous lesson showed.

Line length and line height set how far a reader gets

A line that is too long loses the reader on the way back to the next line, and one that is too short breaks sentences into fragments. WCAG 2.2 success criterion 1.4.8, a level AAA criterion, asks for lines of no more than 80 characters, or 40 for Chinese, Japanese and Korean, and for line spacing of at least one and a half within paragraphs. MDN gives the same minimum of 1.5 for the main paragraph text and recommends a unitless value, which scales with the font size.

The program estimates characters per line from the column width, assuming an average character is half an em wide:

# How many characters fit on one line of body text? An estimate for a MealBox article, with invented page widths.
# Assumption: an average character of a Latin sans-serif face is about 0.5 em wide (real faces differ).
FONT_PX = 16
CHAR_EM = 0.5
LIMIT = 80                      # the longest line WCAG 2.2 success criterion 1.4.8 (AAA) allows, in characters
PAGES = [(360, 16), (768, 32), (1280, 32)]      # (window width, side margin) in px
CAP_PX = 640                    # a cap on the column: 40 rem at 16 px

def chars(width_px):
    return width_px / (FONT_PX * CHAR_EM)

print("window  column  chars/line  within 80   with a 640 px cap")
for width, margin in PAGES:
    column = width - 2 * margin
    capped = min(column, CAP_PX)
    print(f"{width:>6}  {column:>6}  {chars(column):>10.0f}  {'yes' if chars(column) <= LIMIT else 'no':9}   {chars(capped):.0f} chars, {'yes' if chars(capped) <= LIMIT else 'no'}")
print(f"\nlongest column for {LIMIT} characters at {FONT_PX} px: {LIMIT * FONT_PX * CHAR_EM:.0f} px ({LIMIT * CHAR_EM:.0f} em)")

window  column  chars/line  within 80   with a 640 px cap
   360     328          41  yes         41 chars, yes
   768     704          88  no          80 chars, yes
  1280    1216         152  no          80 chars, yes

longest column for 80 characters at 16 px: 640 px (40 em)

At 360 px the 328 px column holds 41 characters, comfortably short. At 768 px it holds 88 and at 1280 px it holds 152, both over 80. A cap of 640 px on the column, which is 40 em, brings both to exactly 80. The estimate depends on the typeface, so measure the real page when the number is close.

Two more checks decide whether these settings hold in real use. Text enlarged to 200 % or restyled by the visitor must still fit its box. And scripts such as Devanagari need taller line boxes, because their marks rise higher than Latin letters do.

Text that survives enlarging and user spacing, with numbers Pro: opens with a Pro, Premium or Ultimate pass

Devanagari marks that fit the line box, measured from a font file Pro: opens with a Pro, Premium or Ultimate pass

Checking a type system with numbers, before and after Pro: opens with a Pro, Premium or Ultimate pass

Practise

The questions below cover the scale and the line settings, and the first one comes from whichever you have found hardest:

Interview questions

Warm-up: how do you pick the body text size for a new product?

Start from the platform’s default, which is 16 px in browsers and 17 pt on iOS, and treat it as a floor, not a target. Check it against the people who will read it, since long articles and older readers need the default or more. Set the size in rem so that a visitor’s own setting carries through, then test at 200 % and with a real paragraph in every script you ship. Choose the other sizes from a scale by ratio, and keep to three or four on one screen.

Three harder questions follow. Think about what you would measure first, before you open any of them:

Key takeaways

• A type scale is a fixed ratio from a body size that starts at the platform default, and sizes in rem follow the visitor’s own setting.
• A line holds at most 80 characters, so cap the column in em, not in pixels, and measure the real page when the number is close.
• Line height is unitless and at least 1.5 for body text, so that it scales with the font size.
• Text must still fit its box when it is enlarged to 200 % or restyled by the visitor.
• Devanagari marks rise as far as the font’s ascent, so a line height that suits Latin letters can clip Hindi.