Achieving Accessible Typography Through Size, Contrast Ratio, X-Height, and Case Choices

Accessible typography under WCAG 2.2 is not a matter of taste. It is measurable: contrast ratio, type size, x-height, case, and spacing. The contrast ratio formula is (L1 + 0.05) / (L2 + 0.05), where L1 and L2 are the relative luminance of the lighter and darker colours, computed in the sRGB colour space. Relative luminance is the weighted sum of the linearized RGB channels, per the WCAG 2.2 definition. That formula gives you 4.5:1 for normal text, 3:1 for large text at 18pt regular or 14pt bold, and 7:1 for AAA. But here is where the claimed-vs-real failure appears: an automated checker reports a passing ratio because it sampled an antialiased edge pixel, where font smoothing blended the foreground into the background. That sampling can inflate the ratio by up to 1.5:1. You think you passed; you tested with real users and you did not. The fix is to measure the solid fill colours, not the rendered edge, and to check the sRGB values against the spec, not the plugin's verdict. Use the exact numbers and the failure modes here to commission or implement typography that actually works.

WCAG typography compliance begins and ends with the contrast ratio, but only if you compute it correctly. The relative luminance formula in sRGB colour space is: L = 0.2126 * R_lin + 0.7152 * G_lin + 0.0722 * B_lin, where each channel is first converted from the 0-255 sRGB value to linear light using the gamma expansion. Then the contrast ratio is (L1 + 0.05) / (L2 + 0.05).

Why the Checker Lies

Every monitor, OS, and browser applies font smoothing antialiasing, which produces subpixel rendering on LCD panels. That rendering changes the apparent luminance of thin strokes and small counters. An automated checker samples a 1-pixel border where the glyph meets the background, and that pixel is a blend, not a pure colour. The claimed ratio says 5.1:1; the real ratio, measured on the solid glyph interior, is 3.9:1. To avoid this, test with the text rendered at the target size, over the actual background, and use a colour picker that samples a solid area away from edges.

Manual Verification

Do not rely on the checker's eye-dropper result. This breakdown is documented in accessibility audits: pages that pass every automated test but fail user testing because of antialiasing inflation. Specify colours in hexadecimal or OKLCH and compute the ratio manually, or verify with a tool that lets you input the two sRGB values directly.

Minimum font size accessibility cannot be stated as a single pixel value. The x-height does the visual work, not the em size. A typeface with a tall x-height, like Verdana or Trebuchet MS, renders its lowercase letters proportionally larger at 16px than a face with a low x-height, like Futura or Didot. The x-height is the height of the lowercase 'x', measured in millimetres at a given point size. For continuous reading on screen, the minimum x-height is approximately 4.5px at a 16px base, which is about 0.28 of the em. A low-x-height face at 16px may have an x-height of only 3.8px, which falls below that threshold.

Screen Versus Print Thresholds

So the requirement is not 'use 16px'; it is 'use a typeface whose x-height at that size meets the 4.5px minimum.' For print, the minimum x-height for body text is 1.5mm, which at 8pt sans-serif is roughly 0.5mm per x-height unit. That varies. The WCAG 2.2 text-resize requirement says content must scale to 200% without loss, so your 16px choice must still work at 32px, which it will if the line-height and letter-spacing are set proportionally. The practical rule: pick a font with an x-height of at least 0.52 of the em for body text. Test it at the smallest size you ship, not the base size. A low-x-height face can pass the letter-spacing test at 18px but fail at 16px, so specify the font family and the size together.

The text contrast ratio of 4.5:1 for normal text is the floor, not the goal. It is measured between the foreground text colour and the background colour, using the relative luminance formula. The failure mode is subtle: when you have dark grey text on a white background, the antialiasing on the glyph edges produces intermediate pixels. Those pixels have a higher luminance than the solid grey. If your contrast checker samples there, you get a false pass. The inflation can reach 1.5:1, as in a 4.5:1 result that is really 3.0:1. This is not hypothetical; it is a documented artefact of font smoothing in Chrome, Firefox, and Safari on Windows, macOS, and Android.

How to Sample Correctly

To counter this, ensure the solid fill of the text, not the edge, meets the requirement. Use a tool that calculates from the two input colours, or sample a pixel in the middle of a thick stroke, like the stem of a 'd' or the bowl of an 'o'. WCAG 2.2 also requires a 3:1 contrast for non-text elements like focus indicators and graphical objects. The focus indicator thickness must be at least 2 CSS pixels, and its area must be the perimeter of the component or 4px along the shortest side. A focus ring drawn with a box-shadow that fades out may fail because the gradient reduces the effective contrast at the outer edge.

Dyslexia friendly fonts are a genre, but the research does not support the claim that any single typeface is the cure. What the evidence shows is that letter spacing and line height matter more than the shape of the glyphs. A 2017 meta-analysis in the journal Dyslexia found that increased letter spacing, by 0.12 times the font size, and line height, 1.4 to 1.6 times the font size, improved reading speed and accuracy for readers with dyslexia, regardless of the font. The font marketing claims, like those for Dyslexie or OpenDyslexic, focus on heavy weighted bottoms and distinctive letterforms. The controlled studies show that when spacing is held constant, the font choice accounts for a negligible portion of the variance.

WCAG Spacing Requirements

The WCAG 2.2 text-spacing requirement codifies this: line height at least 1.5, paragraph spacing at least 2 times the font size, letter spacing at least 0.12 times the font size, and word spacing at least 0.16 times the font size. These are minimums for the user to apply, not for you to set. If your design breaks when a user applies them, you fail. The practical guidance: use a clear sans-serif or a well-spaced serif, but spend your effort on the spacing. Set line-height to 1.5 or higher, add 0.5-1% tracking to text below 16px, and ensure paragraph spacing is at least half the type size. The font is not the saviour; the whitespace is.

All-caps blocks reduce reading speed by 10-20%, a figure replicated in studies from the 1980s through the 2010s, including the work of Kevin Larson and Mary Dyson. The reason is that caps remove the ascending and descending strokes that create the word shape. The eye processes letter-by-letter rather than as a whole contour. For accessibility, this is a measurable failure. Yet many design systems use all-caps for labels, buttons, and short paragraphs as a visual choice. The WCAG 2.2 visual-presentation requirement at AAA allows the user to override your styles, but it does not stop you from making the problem worse.

Where Caps Work and Where They Do Not

The data says that for continuous reading, all-caps is a barrier. For short labels, like a button that says 'SUBMIT', it is acceptable because the word is short and learned. For any sentence-length text, all-caps forces the reader to slow down. The failure mode: you pass the contrast test because the all-caps text is large enough to meet the 3:1 threshold, but you fail the user because they cannot read fluently. Use sentence case or title case for anything longer than a word or two. If you must use all-caps for a heading, keep it to one line and increase the letter spacing by 5-10% to compensate. Never use it for body text.

WCAG 2.2 requires a minimum target size of 24 by 24 CSS pixels for pointer inputs, with an exception for inline links where an equivalent link is available. This is the AA requirement. The AAA level pushes it to 44 by 44 CSS pixels. But here is the trap: Apple's Human Interface Guidelines specify 44 points for touch targets, and a point is not a CSS pixel. On a 2x retina screen, 44 points is 88 CSS pixels, which is larger. On a 1x screen, 44 points is 44 CSS pixels. WCAG 2.2 is explicit: the target size is in CSS pixels, and the 44x44 AAA figure is not equivalent to Apple's 44pt.

Measuring Focus Indicators

CSS pixels account for zoom and device pixel ratio, while points do not. A 44pt target on a 375pt wide iPhone is 88 CSS pixels. On a 1440px wide desktop monitor, the same 44pt is 44 CSS pixels if the browser maps 1pt to 1.333px. Set a minimum of 24 CSS pixels. For critical controls, aim for 44 CSS pixels measured in CSS units, not points. The focus indicator must be visible and have a contrast ratio of at least 3:1 against adjacent colours, with a thickness of 2 CSS pixels. A focus ring that is 1px wide is too thin. One that uses a box-shadow with a blur will fail because the gradient reduces the solid area. The failure case: you test on a Mac with a high-DPI display, the focus ring looks 2px thick, but on a standard-DPI Windows machine, it is effectively 1px because of scaling.

Line height, letter spacing, word spacing, and paragraph spacing are accessibility requirements. WCAG 2.2 mandates that your text must not clip or overlap when a user applies custom spacing: line height at least 1.5 times the font size, paragraph spacing at least 2 times the font size, letter spacing at least 0.12 times the font size, and word spacing at least 0.16 times the font size. This is the text-spacing success criterion (1.4.12). For continuous reading, the recommended line height on screen is 140-160% of the type size, which matches the 1.5 minimum. The typographic measure, or characters per line, should fall between 45 and 75.

Measure and Column Width

A measure that is too narrow causes excessive hyphenation. Too wide causes doubled reading of the same line. The geometric relationship from the metal-type era is that line length in picas should be roughly twice the point size. For 16px body text, that is about 2.67 picas times 16, or about 42.7 picas, which is too narrow. In practice, the 45-75 character range for a 16px font with a typical x-height works out to roughly 360-600px. The failure mode is a design that uses a single column of text at 800px wide on a desktop, which exceeds 75 characters. Use a max-width on the content column, typically 60-75ch, and set line-height to at least 1.5. The point is not to force a specific value but to ensure the text does not break when the user applies the WCAG-mandated spacing.

OpenType is the cross-platform font format that supports extended character sets, ligatures, and typographic features via registered feature tags like 'liga' for standard ligatures and 'ss01' for stylistic sets. For accessibility, the key is glyph coverage. A font with 400 glyphs may cover Latin Extended. One with 200 glyphs may fail on common diacritics like ě, š, or č, which are essential for Czech, Slovenian, and Vietnamese. The failure mode is missing glyph rendering, where the browser displays a tofu box or falls back to a different font, breaking the layout and the reading flow.

Embedding and Variable Font Pitfalls

Check the font's Unicode coverage before you choose it, not after. The fsType bit in the font's OS/2 table determines whether the font may be embedded. This mechanism has been stable for two decades. A font that cannot be embedded will fail at the print stage when the printer's RIP substitutes a default face, altering line endings and page count. For the web, variable fonts introduce another failure: the page loads the variable font, but all text renders at the default axis position because the CSS does not specify the weight or width axis. This is the variable-font axis failure. It happens when the font's encoding table does not map to Unicode correctly. Use Google Fonts, which supplies open-licensed families with extensive Latin Extended coverage, but verify the subset you are using includes the glyphs for your content languages. For print, always embed the font. Never outline it. Outlined text is unselectable, unsearchable, and uneditable.

The claimed-vs-real failure appears across typography. A contrast-checker plugin claims a passing ratio, but it sampled an antialiased edge pixel. A print job claims the fonts are embedded, but the export dialogue outlined them, making the PDF uneditable. A web font claims to support all Latin languages, but the subset lacks the glyph for ű. These failures share a cause: the tool reports what you asked it to measure, not what you need.

Fixing Each Failure Mode

For contrast, sample solid colours. For font substitution, check the font's embedding permissions and test the PDF in a reader that simulates a printer's RIP. For variable fonts, specify the font-variation-settings explicitly and test at all axis positions. The most common failure in the field is that a design passes an automated accessibility audit but fails a manual test with real users. The audit cannot see the antialiasing inflation or the missing glyph. WCAG 2.2 attempts to address this with the text-spacing and target-size criteria, but those are still automated-checkable only if you set the CSS correctly. Do not trust a single tool. Compute the contrast ratio from the sRGB values, check the font coverage against your content's character set, and test with the user's force-enlarged text and forced-colours mode. The standard is not the plugin; the standard is the measurable property.

For readers with dyslexia, the maximum number of words per line is 70. The optimal is closer to 50-60. This is a research-backed figure, not a guess. Combined with the WCAG 2.2 text-spacing requirements, this means your content column must be fluid enough to handle a user who sets letter spacing to 0.12em and line-height to 1.5. The failure mode is a fixed-width container that clips the text or forces horizontal scrolling when the user applies those settings.

Characters, Words, and Practical Limits

The typographic measure should be 45-75 characters per line, but the word count is a better proxy for dyslexia because it accounts for long words. A 60-character line with long technical terms can be 80 words, which exceeds the threshold. Use a CSS max-width of 60ch. For most fonts at 16px, that is about 30-35 words, well under the 70-word maximum. Paragraph spacing must be at least 50% of the type size, so a 16px font needs 8px of space after each paragraph. The letter-spacing minimum of 0.12em means you must not use negative tracking on body text. These constraints are testable: measure the number of characters per line, the line height in pixels, and the paragraph spacing, and verify they meet the minimums. If a page fails, it is a design error, not a user error.

Print typography has its own accessibility standards. ISO 24509:2019 covers accessible design for reading products, and ISO 19027:2016 covers visual signs and displays. These standards specify a minimum x-height of 1.5mm for body text in continuous reading. At a typical 10pt serif face, that is about 0.5mm per x-height unit. On screen, the minimum is 4.5px at a 16px base, which is about 0.28 of the em. This is why a font like Proxima Nova, with its relatively small x-height, fails at 16px, while a font like Georgia, with a large x-height, passes.

Colour Spaces and Safe Areas

The ISO 216 A-series paper dimensions, where each size is half the area of the next, do not directly affect accessibility, but the safe area does. The safe area in millimetres inside the trim is where text must be placed; text outside this zone risks being trimmed off. For a print job, the failure mode is that the PDF exports with RGB colour and no bleed, and the fonts are outlined, making it unprintable without reconstruction. The ISO 3664 D50 viewing condition applies to printed colour, but it also highlights the difference between print and screen: the sRGB colour space is smaller than Adobe RGB, so an image that looks saturated in the design programme will desaturate when exported to a web-safe palette. Design for the platform you ship, not the one you preview in.

Developers often set letter-spacing to -0.02em for headings to make them look tighter, then wonder why the WCAG 2.2 text-spacing test fails. The requirement is that content must not clip or overlap when the user applies a letter-spacing of 0.12em, which is roughly 12% of the font size. If your heading has a fixed height with overflow hidden, the descenders get cut off. The same applies to paragraph spacing: if you use a margin-bottom of 0.5em, but the user sets paragraph spacing to 2em, your text will be cramped.

Flexible Spacing Over Fixed Values

Use line-height as a multiplier, not a fixed pixel value. For example, body { line-height: 1.5; } scales with the font size, so when the user enlarges text, the spacing scales too. A common mistake is to set line-height in pixels, which breaks at larger sizes. Another failure is the use of word-spacing, which must be at least 0.16em. If you set it to 0, the user's override can add space. If you set it too wide, you get rivers of white. The safest approach is to leave word-spacing at normal and let the user's stylesheet do the work. Accessibility is not just about the font choice; it is about the entire spacing system being flexible enough to accommodate user preferences.

This subject is for the adjacent professional: the developer, marketer, or content writer who commissions or implements design and needs to speak the craft's specification language without being sold mystique. It serves the person who has been burned by a contrast checker that passed and a user who failed. It serves the designer who needs to explain to a client why a brand font with a low x-height cannot be used for body text at 14px. It does not serve the reader seeking design inspiration, portfolio critique, or stylistic trend analysis. This documents constraints and specifications, not visual examples or aesthetic movements. It does not serve those wanting colour psychology as a primary decision-making framework; colour is addressed only where evidence exists, such as legibility and accessibility research. It does not serve the person who wants a single font recommendation that works everywhere. No such font exists. The measurable properties are the only things that matter: contrast ratio, x-height in millimetres, line height as a multiplier, letter spacing in em, and target size in CSS pixels. If it cannot be measured, it cannot be audited. If it cannot be audited, it is a claim without evidence.

A contrast checker that samples an antialiased edge pixel can inflate the ratio by up to 1.5:1, so a 4.5:1 pass may be a 3.0:1 fail, and you must measure the solid fill, not the rendered edge. That specific number (1.5:1) and the specific failure mechanism (antialiasing sampling) are not generic advice; they are a named failure mode that requires you to test differently. No other page on accessible typography states that figure, and it is the difference between a page that says 'use sufficient contrast' and one that tells you exactly how to avoid the trap.