HIF / Documentation / Reading systems

HIF Typography

1. Scope

Typography is the system by which written language, numbers and code become perceivable, navigable and operable. It includes typeface selection, shaping, metrics, hierarchy, composition, localisation, loading, licensing and user adaptation. It is not the selection of a fashionable font.

This document applies to operating systems, applications, websites, documents, data displays, terminals and any interface that presents text.

HIF distinguishes four kinds of guidance:

standard requirement — an externally testable obligation, such as a WCAG success criterion or Unicode conformance rule;
empirical evidence — a result observed with stated people, material, apparatus and measures;
platform convention — behaviour expected in a particular ecosystem;
heuristic — a useful starting point that still requires testing in the product context.

A heuristic number MUST NOT be presented as a biological constant or a conformance threshold.

2. The typographic system

2.1. Required roles

A Product Profile defines, at minimum:

reading text;
interface text and control labels;
display and page titles;
section and subsection headings;
supporting and metadata text;
numeric and tabular data;
code, paths, identifiers and terminal output;
captions, annotations and footnotes;
emergency, warning and status text.

One family MAY fulfil several roles. A role is a contract, not a point size: it includes family, fallback, size, line height, weight, width, tracking, features, colour, wrapping, truncation and responsive behaviour.

2.2. Useful type classifications

Serif, sans serif, slab serif, monospaced, humanist, grotesque, geometric and transitional are historical or formal classifications. They can help describe a design, but do not predict accessibility or suitability on their own.

More operational distinctions are:

text face versus display face;
static family versus variable family;
proportional versus fixed-pitch spacing;
low versus high stroke contrast;
compact versus normal versus extended width;
general-purpose versus script-, language- or domain-specific design;
screen-hinted versus primarily print-oriented production;
text fonts versus symbol, colour or emoji fonts.

HIF does not accept “serif is readable” or “sans serif is accessible” as a complete selection rationale.

2.3. Anatomy and metrics

Evaluation SHOULD inspect rendered words and passages, not isolated specimen letters. Material properties include:

x-height and cap height relative to the em;
aperture and counter openness;
differentiation of I, l, 1, O, 0, rn, m, punctuation and quotation marks;
stroke contrast, joins and terminals;
character width and side bearings;
kerning and mark positioning;
ascender, descender and line-gap metrics;
diacritic clearance;
weight progression and width progression;
small-size rasterisation on target displays.

A large x-height can make lowercase forms appear larger at the same CSS font-size, but it is not automatically more legible: counters, spacing, stroke density and word shape interact. font-size-adjust and metric overrides MAY be used to preserve a more comparable perceived size and layout across fallbacks.

3. Reading evidence and its limits

3.1. Legibility and readability

Legibility concerns identifying characters and words. Readability concerns sustained reading and understanding in a complete composition. Comprehension, fatigue, preference and reading speed are different outcomes and MUST be measured separately when they matter.

Reading depends on visual angle, viewing distance, contrast, acuity, font metrics, language, familiarity, display quality, task and reader. A CSS pixel or typographic point is therefore not a universal physiological unit.

Legge and Bigelow's review relates fluent reading to angular print size and x-height across particular vision-science evidence. It supports testing size against viewing conditions; it does not establish one universal digital body size.

3.2. Family, serif and disability claims

Studies comparing families are bounded by the exact faces, sizes, spacing, participants and text used. The Rello and Baeza-Yates study, for example, compared twelve fonts with 48 participants with dyslexia. It does not prove that one family is optimal for every language, age, impairment or task.

HIF therefore requires:

no claim that a commercial “accessible font” treats or solves dyslexia without direct, relevant evidence;
no substitution of disability stereotypes for evaluation with disabled people;
support for user-selected fonts and spacing where the environment permits;
testing of the actual family, weight, rendering stack and content.

3.3. Measure, leading and spacing

Line length affects eye movements, navigation to the next line, scrolling and the ability to compare material. Controlled screen-reading studies show interactions among line length, reading speed and outcome. They do not justify a universal optimum.

WCAG 2.2 Success Criterion 1.4.8, at AAA, specifies user-selectable visual presentation including a width no greater than 80 characters (40 for CJK), non-justified text and specified spacing conditions for blocks of text. These are conformance conditions at that level, not proof that every paragraph should be exactly 80 characters.

Starting heuristics for prose MAY be:

roughly 45–80 average characters per line for sustained Latin-script reading;
a used line height around 1.4–1.6 times body size;
shorter measures for narrow annotations and longer measures only when scanning or data comparison benefits;
extra clearance for scripts with stacked marks or tall ascenders and descenders.

These values require verification with the actual script, family, viewport, zoom level and task. Line height is judged by the distance between baselines and the resulting white space, not by a token number alone.

3.4. Hierarchy evidence

Hierarchy is detected through several correlated cues: order, position, space, size, weight, style and colour. HIF treats a modular type scale as a composition heuristic, not a perceptual law.

A hierarchy is successful when people can:

identify the page and current section;
scan headings in the intended order;
distinguish labels, values, help and status;
resume after interruption;
understand which differences are semantic rather than decorative.

4. Choosing a family

4.1. Gate criteria

A candidate family does not proceed to aesthetic comparison until it passes:

rights to use, modify where needed, subset, embed and distribute it in every target channel;
trustworthy provenance and reproducible font files;
complete coverage of required scripts, characters, symbols and OpenType behaviour, or an engineered fallback plan;
required weights, styles and widths without harmful synthetic faces;
acceptable rendered legibility on the lowest-quality supported display;
acceptable byte and loading cost;
compatibility with text enlargement, user overrides and platform shaping;
stable metrics across releases, or a managed migration.

Brand fit is evaluated only after these gates.

4.2. Reading face

Evaluate a reading face with real long-form material, mixed punctuation, emphasis, links, lists, quotations and supported languages. Check:

comfortable word texture rather than isolated glyph beauty;
open counters and adequate differentiation at the smallest supported size;
italic and bold that remain distinct without becoming noisy;
marks and diacritics that do not collide;
punctuation that is visible but not dominant;
line breaking and hyphenation in real content;
acceptable results under low vision, glare and low-quality rendering.

4.3. Interface face

Evaluate an interface face in buttons, menus, tree views, tabs, form controls, notifications and dense tables. Check:

short-label recognition;
distinguishable states and weight steps;
stability at small sizes;
narrow-space performance without compulsory condensation;
alignment beside icons and platform controls;
numerals and punctuation used in status, time and shortcuts;
the effect of localisation expansion.

4.4. Monospaced face

Fixed pitch is justified where columns or character identity carry meaning: source code, terminal output, hashes, aligned logs and some identifiers. A monospaced family SHOULD distinguish ambiguous characters and provide the required programming symbols. It SHOULD NOT be applied to all technical prose.

The interface MUST NOT rely on monospacing alone to preserve a data relationship that semantics or table structure should express.

4.5. Pairing families

Multiple families increase hierarchy options but also increase loading, licensing, localisation and maintenance cost. Pair families only when each has a defined role. Compare:

x-height and apparent size;
stroke contrast and colour on the page;
proportions and rhythm;
weight compatibility;
language coverage and fallback transitions;
numeral, punctuation and symbol compatibility.

“Contrast with compatibility” is a design heuristic, not an acceptance test.

5. Hierarchy and composition

5.1. Type scale

Define semantic steps before numeric steps. The number of steps is driven by content architecture. Adjacent roles MUST remain distinguishable in context, including at zoom, in high contrast and when colour is removed.

A scale SHOULD:

avoid near-duplicate roles;
use fluid sizing only within bounded, tested limits;
prevent display sizes from consuming the working viewport;
preserve readable body text independently of viewport width;
include compact and large-content adaptations.

5.2. Weight, width and style

Weight is not a substitute for hierarchy structure. Very light text often loses strokes; very heavy text can close counters. Test the actual rasterised instance.

Condensed widths MAY support headings or dense data, but MUST NOT be used to hide localisation overflow or preserve an arbitrary layout. Italic and oblique styles are appropriate for bounded emphasis, terms or citation conventions; long passages require direct readability evaluation.

Synthetic bold, italic or small capitals SHOULD be disabled where they distort forms or reduce differentiation. Use designed faces or features.

5.3. Case and decoration

All-capital text changes word shape and often requires tracking adjustment. It MAY be used for short, conventional labels after testing, but SHOULD NOT be the default for prose or long control labels. Letterspacing MUST NOT be used to simulate justification or repair a fundamentally unsuitable face.

Underlining remains a strong learned signal for links on the web. If another use of underlining creates ambiguity with links, change the other use.

5.4. Truncation and wrapping

Wrapping is preferred when complete content matters. Truncation requires:

a defined necessity;
preservation of the start, end or middle according to the information type;
access to the complete value by an operable method;
correct handling of grapheme clusters and bidirectional text;
testing with localised extremes and user enlargement.

An ellipsis is a visual state, not a complete accessible-name strategy.

6. Optical sizes and variable fonts

OpenType variable fonts can represent continuous or named instances along registered axes such as weight (wght), width (wdth), slant (slnt), italic (ital) and optical size (opsz), plus family-specific axes.

Use high-level CSS properties for registered axes where possible. They participate in matching and cascade independently. Use font-variation-settings for axes that have no suitable high-level property.

Optical sizing changes glyph design for intended rendered sizes; it is not geometric scaling. When a family provides a valid opsz axis, font-optical-sizing: auto MAY improve small- and large-size instances. Test browser behaviour, supported range and every critical role. Do not fake optical sizes with tracking or stroke effects.

A variable file is not automatically smaller than every static-font subset. Compare the compressed files and required axes for the actual character set. Pin axis ranges in @font-face accurately, and test intermediate values rather than assuming that interpolation preserves quality.

7. Numbers, data and code

7.1. Numbers

Use locale-aware formatting for decimal, grouping, sign, currency, percentage, unit, compact notation and numbering system. Do not insert separators by string replacement.

OpenType numeric features MAY select:

proportional figures for prose;
tabular figures for columns and values that update in place;
lining or old-style figures according to the textual role;
slashed zero where ambiguity is material;
fractions, ordinals and scientific notation when supported and verified.

Tabular figures align glyph advances, not decimal semantics. Decimal alignment, headers, units, precision and uncertainty still require explicit data design. Do not round away a material distinction.

7.2. Code and identifiers

Code typography SHOULD support:

unambiguous letters, digits and punctuation;
visible whitespace where the task requires it;
long-line wrapping or two-dimensional scrolling according to meaning;
selection and copy without injected line numbers or decoration;
bidirectional and invisible-character inspection where source integrity is at risk;
zoom and user-selected family;
syntax highlighting that is redundant to text, structure or decoration.

Ligatures that replace several programming characters MAY be offered as a user preference but MUST NOT obscure the underlying sequence or prevent precise cursor placement.

8. Multilingual and multi-script typography

8.1. Language and script support

“Supports Unicode” is not an acceptance statement. Record:

required languages and scripts;
normalisation, grapheme, line-break and shaping expectations;
required punctuation, currencies, mathematics and symbols;
vertical writing, ruby or emphasis requirements where applicable;
default and optional numbering systems;
input, editing, search, selection, copy and export behaviour.

Test native content, not transliterated placeholders. Review with readers and type specialists of the relevant scripts.

8.2. Shaping and fallback

Complex scripts require correct glyph substitution, reordering, mark attachment and language-specific forms. Preserve language metadata and allow the shaping engine to apply required OpenType features.

A fallback stack is a designed composite system. For every fallback boundary, test:

coverage without tofu or missing marks;
compatible apparent size and line metrics;
weight and style matching;
punctuation and numeral ownership;
baseline alignment;
emoji text-versus-colour presentation;
no mid-grapheme or otherwise invalid split.

unicode-range MAY divide resources, but the browser's matching and the actual text corpus must be tested. Subsetting MUST retain shaping tables and required characters.

8.3. Bidirectionality

Store text in logical order and implement the Unicode Bidirectional Algorithm. On the web, use language and direction metadata, logical CSS properties and HTML dir, bdi or bdo semantics as appropriate. Do not repair mixed direction by manually reversing strings or inserting visual spaces.

Test mixed-script names, numbers, punctuation, paths, telephone numbers and user-generated text inside both left-to-right and right-to-left interfaces. Mirror directional icons only when their meaning is spatial or textual; do not mirror universal or physical-object meanings automatically.

9. Accessibility and user control

Typography MUST survive the applicable accessibility baseline. For WCAG 2.2 web content this includes, according to the selected conformance level and scope:

text resized to 200% without loss of content or function;
reflow at the specified equivalent viewport;
no loss when users apply the text-spacing values in Success Criterion 1.4.12;
required text and non-text contrast;
images of text avoided except for defined exceptions;
content and controls remaining available under user styles and platform accessibility settings.

Products SHOULD additionally test:

browser zoom to 400%;
operating-system text scaling and large-text settings;
minimum and maximum supported viewport;
a user font override;
increased line, paragraph, letter and word spacing;
bold-text, high-contrast and forced-colour modes;
low-resolution, magnified and remote-display rendering.

Do not lock text size, disable zoom, encode prose as paths, or make a container clip solely to preserve a composition. User preferences take precedence over brand-perfect line breaks.

10. Web-font engineering

10.1. Formats and resources

WOFF2 is the W3C web-font format for current web delivery. Retain source font artefacts separately when licences allow; a WOFF2 file is a delivery resource, not the design source.

Create the smallest justified set of resources:

subset by measured language corpus and supported features;
split by script only when loading behaviour and fallback remain correct;
omit unused axes and instances where the licence and tooling permit;
declare correct weight, style, width and variation ranges;
serve with correct MIME type, caching and cross-origin policy.

Every subset requires a missing-glyph and shaping regression test.

10.2. Loading policy

The font-loading plan records:

which text is useful before custom fonts arrive;
which fonts are critical to first render;
acceptable flash of unstyled or invisible text;
font-display policy per role;
preload justification;
timeout and failure behaviour;
layout-shift budget;
slow-network and repeat-visit results.

Body text SHOULD normally remain available during font failure. Preload only resources whose early use is certain; unnecessary preloads compete with more important work.

Fallback metrics can be adjusted using size-adjust, ascent-override, descent-override and line-gap-override to reduce layout movement. These values MUST be derived from measured font metrics and tested for clipping. Avoid hiding already-readable text merely to wait for a branded face.

10.3. Performance evidence

Record for each route and locale:

compressed font bytes requested and used;
request start, completion and cache behaviour;
text render timing;
layout shift attributable to font replacement;
unused glyph, feature and axis cost;
failure result with blocked requests.

Performance is an acceptance property of the full typographic system, not a claim inferred from the word “variable” or “subset”.

11. Licensing, provenance and security

For each font file, keep:

asset identifier and cryptographic hash
family, foundry and designer
source URL and acquisition date
licence name and exact licence/EULA file
permitted products, platforms and territories
web embedding, app embedding and document embedding rights
modification, conversion and subsetting rights
redistribution and server/CDN rights
attribution and naming requirements
version and modification history
internal owner and review date

An “open” label without the actual licence is insufficient. A desktop licence does not imply web, application or redistribution rights. Do not download production fonts from unofficial mirrors or copy them from another product.

Font binaries are executable input to complex parsers. Use maintained tooling, validate files, preserve hashes and deliver only the tables and features that are required.

12. Typography tokens

Recommended semantic token fields:

role
family and fallback
size or bounded fluid function
line height
weight
width
style
letter spacing
word spacing
OpenType features
variation axes
text transform
decoration
wrapping and overflow policy
language/script overrides
platform override

Example:

type.body.default
type.body.compact
type.heading.page
type.label.control
type.data.tabular
type.code.default

Primitive tokens such as font-size-300 MAY support implementation, but components consume semantic roles. A theme or brand override MUST preserve the role's accessibility, script coverage, layout and performance contract.

13. Selection algorithm

Use the following reproducible process:

define people, languages, scripts, tasks, devices and viewing conditions;
inventory all textual roles and extreme content;
set legal, accessibility, platform and performance gates;
form a candidate set with authoritative source and licence evidence;
run coverage, shaping, ambiguity, metric and binary validation;
compose real screens and long-form passages at all required sizes;
test fallback, failure, zoom, spacing overrides and localisation;
compare task performance, comprehension, error, preference and fatigue without collapsing them into one score;
test disabled readers and relevant language communities;
choose by the predeclared decision rule and record residual risks;
encode semantic tokens and component contracts;
freeze artefact hashes, licences, subsets and regression specimens;
monitor field evidence and review when fonts, content or platforms change.

Do not select a family from a logo specimen, one English marketing screen or a stakeholder vote alone.

14. Acceptance matrix

Dimension	Required evidence	Reject when
Rights	Exact licence and distribution review	Any target use, subset, embed or redistribution right is absent
Provenance	Authoritative files, version and hashes	Origin or modification history is unknown
Coverage	Corpus scan plus native-script specimens	Required glyph, mark, feature or shaping fails
Legibility	Character, word and passage tasks on target displays	Material ambiguity or loss occurs at a supported condition
Readability	Representative sustained-reading task	Comprehension, speed or fatigue misses the declared threshold
Hierarchy	Scan and comprehension test in real layouts	Roles cannot be reliably distinguished
Accessibility	Zoom, reflow, spacing, contrast and user-override tests	Content or function is lost
Data/code	Numeric, identifier and code corpus	Alignment implies false meaning or characters are ambiguous
Localisation	Long, short, mixed-direction and multi-script content	Clipping, invalid order or fallback discontinuity occurs
Performance	Cold/warm load and failure measurements	Budget or rendering availability threshold is missed
Stability	Cross-browser/platform visual regression	Metrics or breaks change outside tolerance
Operations	Tokens, owner, source and review record	The family cannot be maintained reproducibly

Thresholds, devices and samples MUST be set by the Product Profile before final comparison.

15. Release checklist

All visible text remains real, selectable text unless an exception is documented.
Headings and roles follow semantic structure rather than visual size alone.
Every shipped weight and style is a designed or explicitly accepted instance.
All supported scripts have native-content review.
Fallback and blocked-font states have been tested.
Zoom, reflow and text-spacing overrides lose no required content or action.
Numeric precision, locale and alignment are correct.
Code and identifiers preserve exact character sequences.
Font requests, bytes and layout shift meet the Product Profile.
Licences, hashes, attribution and source files are recorded.
Regression specimens cover critical strings, scripts and layout boundaries.