Typography

Font families

Why system fonts

• Zero download cost — no web font requests, instant text render
• Native feel — text matches the OS, builds familiarity and trust
• Performance — critical for users on 3G / low-end devices
• Localization-ready — system fonts handle non-Latin scripts automatically
• Pipeline-compatible — the Figma MCP server does not return custom typefaces. A system stack is the one choice that survives design-to-code without manual repair.

The performance argument is not theoretical. A webfont is a render-blocking request on the critical path; on a metered 3G connection it delays the moment a user can read their balance. Senco's audience is defined by that connection.

Why Arial for documentation

• Universal availability — installed on every OS, renders in all email clients
• Consistent rendering — PDFs, print, and email look identical across devices
• Professional tone — clean, neutral, appropriate for financial documents
• Email-safe — no fallback surprises in transactional emails (receipts, confirmations)

system-ui is not available in email clients, and a receipt that renders in Times New Roman on one client and Helvetica on another undermines the one document a user is most likely to forward to their bank.

The two stacks never mix

In-product text is always --ds-font-sans. Exported artifacts — receipt PDF, confirmation email — are always the documentation stack. A receipt shown in the app uses the product stack; the same receipt emailed uses Arial. The switch happens at the export boundary, not per component.

Type scale

Font: system-ui (--ds-font-sans) · Ratio: 1.200 (Minor Third) · Base: 16px · Grid: 4px line-height

Implemented size tokens

These are the values defined in ds.css. Every type role resolves to one of them.

Letter-spacing rule

Larger text needs tighter tracking; smaller text needs looser tracking for legibility.

Only one tracking value is tokenized: --ds-tracking-tight (-0.02em), applied to Display and H1. The rest are applied per role.

Line-height rule

Headings

H2 and H3 use weight 700 rather than 600 so they qualify as WCAG "large text" (bold ≥ 18.66px / 14pt), which lowers their contrast requirement to 3:1. H4 at 18px/600 does not qualify — it is semibold, not bold — so H4 must clear the full 4.5:1. This is the single most commonly missed contrast rule in the system, because the heading looks large.

Body

10px text is capped at non-essential content by rule. Nothing a user must read to complete or verify a transfer may be set at --ds-text-2xs. If a fact matters, it gets 12px minimum.

Weight scale

Four weights, no more. System stacks do not carry a reliable 300 or 800 across platforms, and a weight that renders on macOS and silently snaps to 400 on Android is a design decision that only exists on the designer's machine.

Responsive scaling

Headings scale up on desktop. Body text stays fixed — the reading task is the same size on every device.

H1 uses clamp() rather than a breakpoint so the page title scales continuously. Every other level steps at the breakpoint.

Do and don't

Currency & numbers

Senco handles money — number rendering must be clear and consistent.

• Use font-variant-numeric: tabular-nums for aligned columns in transaction lists, exchange rates, and amount displays
• Use the system sans-serif font (not monospace) for all financial data
• Account balances use Display size (40px) at weight 700

Why tabular, not monospace

Proportional numerals shift column alignment row to row, which makes a transaction list impossible to scan for an outlier. Monospace fixes alignment but reads as code and carries the wrong tone for a balance. tabular-nums gives fixed-width digits inside the system sans — alignment without the terminal aesthetic.

Amount composition

An amount is not one text run. It is composed so that magnitude dominates and denomination stays legible:

Cents step down one size rather than changing color. Dimming the cents makes the amount read as rounded, which in a fee breakdown is exactly the wrong impression.

This composition applies to amounts that are displayed — balances, receipts, fee rows. An amount being typed into a field is a single run at the field's size, because an <input> renders one font size.

Formatting rules

• Group separators and decimal marks follow the recipient's locale on the receive side and the sender's on the send side. Both are labelled with the currency code so the two are never ambiguous.
• Currency code (USD, NGN, PHP) always accompanies an amount. A bare number in a multi-currency product is a defect.
• A displayed amount has a spoken form. The visible text keeps the compact code and is aria-hidden; a visually hidden sibling carries the currency name, so a screen reader says "1,250.00 US Dollar" rather than spelling out "U S D".

<span aria-hidden="true">1,250.00 USD</span>
<span class="sr-only">1,250.00 US Dollar</span>

This applies only to amounts that are displayed. An amount inside an editable field is read as typed, and its currency is supplied through the field's description — see Amount input.

• Negative amounts use a leading minus and --ds-error-text, never parentheses. Parentheses are an accounting convention that does not survive screen readers.
• Exchange rates render at exactly 6 significant figures; amounts render at the currency's minor-unit precision (2 for USD, 0 for JPY). See Tokens.
• Times are absolute, 24-hour, in the user's local time zone. Never relative ("2 hours ago") — a relative time read later is wrong, and in a screenshot sent to support it cannot be answered.
• Same calendar day: time only — 10:42. Earlier in the current year: 12 Mar, 10:42. Earlier years: 12 Mar 2025, 10:42. Month names come from the locale through Intl.DateTimeFormat, with hourCycle: "h23" fixed.
• Status timestamps: a non-terminal status reads {Status} since {time} — Pending since 10:42. A terminal status reads {Status} · {time} — Completed · 12 Mar, 10:42.

Documentation typography

For emails, PDFs, and external documents, use Arial to ensure consistent rendering across all clients and devices.

Doc body is 14px where product body is 16px. Email and PDF are read at a closer viewing distance on a settled screen, not one-handed on a moving train.

Accessibility

• Heading hierarchy must be sequential — no skipping levels (h1 → h2 → h3)
• Body text line height minimum 1.5 for readability
• Minimum readable text size: 10px (--ds-text-2xs) — weight 500, positive letter-spacing, non-essential content only
• Text spacing must be adjustable without loss of content (WCAG 1.4.12)
• Support assistive technology navigation via semantic heading structure
• Contrast: 4.5:1 for normal text, 3:1 for large text (≥18.66px bold or ≥24px)
• Sizes are set in rem, so browser and OS text-size settings scale the interface. No type token uses px.
• Text must reflow without horizontal scrolling at 320px width and 200% zoom (WCAG 1.4.10)

Known gaps and drift

These are places where this spec and ds.css do not currently agree. They are listed rather than reconciled silently, because an agent generating code from this file needs to know which lines are contracts.