Accessible Typography: Improve Readability for All

WCAG 2.2 has no opinion on which font you pick. It names no typeface and no minimum font size. What it measures is contrast ratios, text resizing to 200 percent, reflow at 320 CSS pixels, and whether a layout survives spacing changes.

A systematic review of 42 peer-reviewed studies (Ho Sang and Petrarca, Visible Language, 2025) found no single typeface or type size that works best for every reader. The authors lean toward letting readers adjust size and spacing themselves over recommending one font.

What Is Accessible Typography?

The term covers how typeface, size, contrast, spacing, and layout get set so that people with low vision can read the text, along with people who have dyslexia or cognitive disabilities. It applies to screens, documents, and print. It is a set of settings, not a font category.

Two words get mixed up constantly. Legibility is how easily a reader picks out individual letters and words, and that mostly depends on how the typeface is drawn. Readability is wider. It covers how comfortably someone gets through a whole passage, so size, spacing, line length, and contrast all count along with the typeface.

Ho Sang and Petrarca (Visible Language, 2025) use the same definitions. They add that readability also depends on non-design factors such as vocabulary and reading conditions.

web.dev counts readers with dyslexia or ADHD among those who benefit from accessible typefaces, along with people who have low vision. Its typography module treats page layout as equally important to typeface choice.

Typography sits inside wider web accessibility work. It’s also where a single styling choice, say 11px light gray text, can lock out a whole group of readers.

Layout carries the other half. A clear visual hierarchy between headings and body text (captions too) shows readers where sections start, which counts most when a screen magnifier displays only a slice of the page.

Which Text Rules Are Required and Which Are Only Recommended?

As of October 2026, WCAG 2.2 requires text contrast, text resizing, reflow, and spacing tolerance at Level AA. Typefaces and minimum sizes aren’t on the list. Section508.gov says the same about Section 508, with one narrow exception covered below.

Plenty of typography guides claim WCAG requires 1.5 line height and 0.12em letter spacing in body text. That’s not quite what the criterion says.

Level AA only requires that nothing breaks when a user applies line height of 1.5, paragraph spacing of 2x the font size, letter spacing of 0.12em, and word spacing of 0.16em. W3C’s Understanding document for SC 1.4.12 states that content is not required to use those values.

The authored values sit one level up. Under 1.4.8 (AAA), line spacing is at least 1.5 and paragraph spacing at least 1.5 times the line spacing, a different base from the 2x font size in 1.4.12.

Legal weight differs by region, because each froze its baseline at a different WCAG version.

In the United States, the Access Board’s final rule of January 18, 2017 incorporates WCAG 2.0 Level A and AA, with compliance required from January 18, 2018. Reflow and text spacing arrived with WCAG 2.1 in June 2018, so neither appears in the codified Section 508 text.

The European Union is further along. The European Accessibility Act applies from 28 June 2025 and relies on EN 301 549 as its technical reference. Version 3.2.1 (2021) is built on WCAG 2.1, so reflow and text spacing are in scope there. EN 301 549 version 4.1.1, published 2 September 2026, moves the baseline to WCAG 2.2 and becomes binding once the European Commission cites it in the Official Journal of the EU, according to the National Disability Authority.

Section 508 names a typeface class in just one place, ICT with closed functionality, such as kiosks and self-service machines. Provision 402.4 requires at least one display mode in a sans serif font, plus 3/16 inch (4.8 mm) characters, measured on uppercase I, where the screen has no enlargement feature.

ADA and ABA signage standards also call for sans serif characters (Section508.gov).

Success Criterion 1.4.5 (AA) asks for real text instead of images of text. The exceptions are text the user can customize and presentations where the exact look of the text carries the information, such as logotypes.

What Makes a Typeface Accessible?

What matters is whether the letters stay distinct when they get small. Open shapes help, a tall x-height helps, and so do strokes in the medium-to-heavy range.

Look-alike characters are the first thing to check. I, l, and 1 need different shapes, and so do O and 0, and g and q. Otherwise context is the reader’s only clue.

Fontsmith’s research with Mencap found that open counter shapes aid reading, and it lists a large x-height with moderate-to-wide proportions as the most accessible profile. Stroke weight matters too, since strokes lighter than regular slowed reading speed in Beier and Oderkerk’s 2019 test.

Sawyer and colleagues’ 2020 glance-legibility comparison of common sans serif interface typefaces points the same way. Frutiger ranked first, Gill Sans last, and open letter shapes beat closed ones (Ergonomics).

Arial gets recommended more than any other typeface. RNIB names 14pt Arial as ideal, and Round Table and CNIB list it too, according to Ho Sang and Petrarca’s review.

The same review found other typefaces matching or beating Arial in two studies (Sieghart, 2023; Wallace et al., 2022). It notes that Arial’s ubiquity may shape how legible it feels.

web.dev’s practical reading is that Arial, Times New Roman, Calibri, and Verdana aren’t inherently more accessible. Readers who spent years with them just find them easier.

Test a typeface on its own confusable characters at body size. A category label proves nothing, and I’d trust that check over any “best fonts” list.

Sans Serif vs. Serif: What the Research Says

The evidence doesn’t pick a winner. Ho Sang and Petrarca’s 2025 systematic review of 42 peer-reviewed studies concludes that serifs are not a significant legibility factor.

Of the 19 studies in that review that compared the two, 2 favored sans serif, 3 favored serif, and 14 returned null, inconclusive, or conditional results.

Some sources do lean toward sans serif.

• Fontsmith’s research with Mencap rates sans serif the most accessible style for readers with reading disabilities
• Section508.gov holds that serifs significantly degrade legibility for people with low vision
• Rello and Baeza-Yates (2013) recorded shorter fixations on sans serif fonts among 48 readers with dyslexia, though reading time did not differ

Arditi and Cho (2005) found no serif effect for readers with low vision, using custom typefaces identical except for serifs, in a small sample. Perea (2013) found no significant effect on eye movement measures.

A Springer chapter reviewing Rello and Baeza-Yates argues that the typefaces were not matched for spacing, which confounds typeface with letter spacing.

The sans serif preference has a history. Serif detail rendered poorly on low-resolution displays (Bernard et al., 2003), and the review notes that some modern displays now exceed high-resolution print.

For readers with low vision, Minakata and colleagues (2023) found the pairing mattered more than the category. Serif with low stroke contrast and sans serif with high stroke contrast performed best.

The evidence base is thin where it matters most. About 7 percent of the 3,323 participants across the 42 studies had a disability.

Choose on letterform distinctness, x-height, and stroke contrast. Treat sans serif as a requirement only in the closed-functionality cases Section 508 names.

Do Dyslexia-Friendly Fonts Work?

The peer-reviewed tests don’t back the specialist fonts. OpenDyslexic and Dyslexie both showed no reading gain over common typefaces.

Wery and Diliberto (Annals of Dyslexia, 2017) compared OpenDyslexic with Arial and Times New Roman in elementary students identified with dyslexia and saw no improvement in reading rate or accuracy. The International Dyslexia Association pairs that result with a December 2017 Annals of Dyslexia study of the Dyslexie font, which reached the same conclusion.

Rello and Baeza-Yates’s 2013 eye-tracking test points the same direction. Helvetica and Courier produced the shortest fixations, and OpenDyslexic did not beat the common sans serifs.

Google Fonts published Lexend in August 2019, and the family is also available in Google Docs. Braille Institute released Atkinson Hyperlegible as a free font under the SIL Open Font License in 2019.

The 2025 review excluded specialist typefaces from its scope, so it settles neither Lexend nor Atkinson Hyperlegible.

Wallace and colleagues (ACM Transactions on Computer-Human Interaction, 2022) tested 352 participants and found readers 14% faster in their fastest font than in their preferred one, and 35% faster than in their slowest. The fastest font differed from person to person.

Offering a typeface switch is fine. Keep a familiar sans serif as the default, though, and put size and spacing controls ahead of it. The review’s authors suggest those controls may help more than typeface pickers.

What Font Size Should Body Text Be?

Body text on the web sits at 15 to 16px and in documents at 11 or 12pt (Section508.gov), because WCAG sets no minimum size.

Other formats drift from that. Documents run 12pt or larger according to the Australian Government, and 12 to 18pt depending on the font according to CNIB. Slides go to 24pt or larger (Portland State University), while email sits at 10 to 11pt or 13 to 15px (Section508.gov).

In Sieghart’s legibility study (Design Issues, 2023), 12 or 12.5pt was large enough for 93.7% of 145 participants with undisclosed disabilities. The results put a question mark over the common 14pt Arial advice.

Sieghart and Sheedy and colleagues (2005) both found a plateau, past which larger type added nothing.

Point sizes also mislead across typefaces, because x-height varies at the same point size (van der Waarde and Thiessen, Visible Language, 2025). Ho Sang and Petrarca suggest comparing x-height in millimetres for print and visual angle for screens.

Section508.gov explains the low-vision cost of small type. Magnification tuned to 11 or 12pt text gives a very narrow field of view (the site compares it to looking through a soda straw), so smaller fonts force more zooming, and running text under 9pt, such as a long footnote, creates a barrier.

Very large type has the opposite problem. Readers zoom out and lose their place.

WCAG measures large text in points: 18pt, or 14pt bold, which works out to about 24px and 18.5px at 1pt = 1.333px (W3C, Understanding SC 1.4.3). When a style guide mixes units, convert pixel sizes to points before checking those thresholds.

The 16pt figure that circulates comes from Section 508 provision 402.4: 3/16 inch characters, measured on uppercase I, where a screen has no enlargement feature. Section508.gov warns against applying it to electronic documents, where readers control zoom.

Pick the size by x-height, then test it at 200 percent zoom.

How to Size Text So It Scales and Reflows

Relative units come first. The browser or operating system multiplies them, and flexible containers let the layout reflow at 320 CSS pixels wide.

Scaling Text on the Web

MDN advises using values relative to the user’s default font size, and it flags px as static because some browsers cannot resize it.

A px value is fixed. Em and rem both scale, but em multiplies the parent’s size, so nested elements compound, while rem multiplies the root element’s size and nesting changes nothing.

MDN’s compounding example makes the gap concrete. With a 16px default, a span at 1.6em renders at 25.6px, while a span nested inside it renders at 40.96px.

Use rem units for the type scale, and keep em for components that should follow their own text size.

SC 1.4.4 asks for 200 percent enlargement, not a fixed CSS size. W3C’s Understanding document lets 20px text drop to 10px at a 320px breakpoint, because at 400% zoom it still displays at twice its 100% size.

clamp() takes a minimum and a maximum with a fluid value in between. Keep both bounds in rem.

Scaling Text in iOS and Android Apps

On Android, specify text and line height in sp units (Android developer documentation). Starting in Android 14, the system scales fonts up to 200% along a nonlinear curve that preserves proportions between large and small text.

Do not use sp for padding or view heights. With nonlinear scaling, 4sp + 20sp might not equal 24sp.

On iOS, Apple’s guidelines say Dynamic Type lets people choose text size across iOS, iPadOS, tvOS, and watchOS, and that text styles bundle weight, point size, and leading. A hard-coded system size such as 17 point does not scale.

Apple’s WWDC 2017 session describes seven standard sizes plus five accessibility sizes, and since iOS 11 every text style adapts across all 12.

Layouts that hold at the largest setting belong to wider mobile app accessibility work, which covers far more than text.

What Contrast Ratio Does Text Need?

AA sets the floor at 4.5:1 for text and 3:1 for large-scale text, and AAA raises those to 7:1 and 4.5:1.

Most sites still miss even the lower numbers. WebAIM found low-contrast text on 83.9% of the top one million home pages in February 2026, up from 79.1% in 2025, averaging 34 instances per page.

That makes color contrast the most commonly detected failure in the same report.

The 4.5:1 figure starts from a 3:1 baseline in ISO 9241-3 and ANSI/HFES 100-1988, multiplied by about 1.5 for the contrast sensitivity loss tied to 20/40 vision (W3C, Understanding SC 1.4.3). The 7:1 figure applies the same logic to 20/80 vision, the point where people usually move to assistive technology with built-in contrast enhancement.

The thresholds are hard cutoffs with no rounding, so 4.499:1 fails. Hue is not a key factor in the formula.

Placeholder text, hover text, and focus text all count. Logos are exempt, but brand guidelines do not exempt any other text.

Thin typefaces break the arithmetic. Anti-aliasing can render them fainter than their CSS color, so a nominal pass can fail in practice, and W3C advises thicker strokes or a ratio well above the minimum.

APCA does not change the test. The WCAG 3.0 Working Draft of 10 September 2026 states that the contrast algorithm is yet to be determined, and Adrian Roselli reports that APCA was pulled from the July 2023 draft as exploratory.

Eric Eggert notes that the WCAG 2 ratio ignores font size and weight, which APCA models. For WCAG 2.2 conformance, the ratio is still the test.

TPGi’s Colour Contrast Analyser (listed in W3C’s resources) and WebAIM’s Contrast Checker both compute the WCAG ratio. For palettes, an accessible color palette generator can produce pairs that already pass.

How Much Line Height and Spacing Does Text Need?

Line spacing is the better supported of the two. The letter spacing research contradicts itself.

Ho Sang and Petrarca (2025) conclude that insufficient line spacing causes visual crowding and cuts readability. Dobres and colleagues (2018) found that extra leading did not rescue text that was already too small.

On letter spacing, McLeish (2007) found low-vision readers read faster as spacing grew, and Zorzi and colleagues (PNAS, 2012) reported gains for children with dyslexia. Schneps and colleagues (PLOS ONE, 2013) found added spacing did not speed reading for students with dyslexia, though it raised recall among the weakest readers. They trace the gap to Zorzi’s design, where letter spacing, line spacing, and line width varied together.

Slattery and Rayner (2013) found that words with tighter letter spacing but wider word spacing performed best.

Extra white space between paragraphs is not required for conformance, though W3C notes it helps people with cognitive disabilities discern sections.

The numbers behind those values are worth knowing. In McLeish (2007), reading speed rose with letter spacing from 0.04em to 0.25em and began to flatten at 0.20em. Ho Sang and Petrarca (2025) point to line spacing of at least the type size plus 20 to 30 percent, against a 20 percent default in many layout programs. And in Schneps et al. (2013), a 29 percent letter-spacing increase lifted recall for weaker readers but not reading speed.

The WCAG 3.0 working draft of 10 September 2026 lists line height, line length, and letter spacing values as still to be determined. SC 1.4.12 and the research above remain the working references.

What Line Length and Alignment Work Best?

Medium-length, left-aligned lines suit most readers, and the case for very short lines rests on readers with dyslexia.

Schneps and colleagues (PLOS ONE, 2013) tested 27 students with dyslexia on a phone-sized screen at 12.7 characters per line and a tablet at 67.2. Reading was 27% faster on the short lines, fixations fell 11%, regressive saccades more than halved, and comprehension held.

Dyson and Haselgrove (2001) found medium line lengths read faster than shorter ones on screen. Paterson and Tinker (1940), cited by Schneps, found typical readers did best at intermediate widths, not at long or very short ones.

Columns split the experts. EBU and CNIB recommend them in print to cut eye movement. APH advises against them, because the return to the next line is harder for low vision when lines are short. Ho Sang and Petrarca read the research as favoring multi-column layouts for all readers, with the most benefit for dyslexia.

The disagreement tracks the reader. Schneps and colleagues attribute the dyslexia result to their sample, since short lines helped well below the lengths that suit typical readers.

W3C’s 80-character limit in SC 1.4.8 halves to 40 for CJK text, because CJK characters run about twice as wide. Technique C20 sets column widths with relative measurements so lines stay at or under 80 characters as the window resizes.

Full justification fails SC 1.4.8 (failure F88). Uneven word spacing opens rivers of white space down the page and crowds words together, so word boundaries are hard to find for some readers with cognitive disabilities.

Align text to one side (technique C19) and let lines wrap with the window (G204).

Where Accessible Typography Breaks

Failures here repeat a lot, and nearly all of them come down to something that ignores the reader’s settings.

• W3C failure F94 (updated 9 March 2026) says vw or vh on font-size blocks zoom and text-size changes, and only methods that override the CSS entirely work
• A clamp() or max() that stops text growing can leave users short of 200 percent, which fails SC 1.4.4 (Roselli, 2019)
• Fixed heights and hidden overflow cut headings off under spacing overrides, which is failure F104
• Canvas text counts as an image of text, so spacing overrides cannot reach it (W3C)
• A table’s exemption from reflow does not extend to the paragraphs around it, and sticky bars cover zoomed content (W3C)

Roselli’s test case uses clamp(1.5rem, 5vw, 3rem). Browsers do not scale viewport units on zoom. In Roselli’s tests, Firefox stopped at 300% zoom while Chrome went higher, so the same page could pass in one browser and fail in the other. Barvian notes that modern browsers now zoom up to 500%, but Safari’s zoom behaves differently, so test in more than one browser.

A style sheet that sizes body text in viewport units cannot pass F94’s test, which asks whether text reaches 200 percent through browser zoom or text size.

Barvian’s analysis for Smashing Magazine (2023) frames the clamp() test as a comparison. The text’s rendered size at maximum browser zoom must be at least double its size at 100 percent.

A CSS clamp calculator shows the bounds, and the zoom test shows whether they hold.

Truncation is allowed when the full text can be revealed. An ellipsis passes if the text appears on focus or activation (W3C, SC 1.4.12).

How to Test Text Accessibility

WebAIM warns that an absence of detected errors does not show a page is accessible or conformant, so an automated scan only gets you part of the way. The manual checks fill in the rest.

1. Check every text and background pair, including hover, focus, and placeholder text, with a WCAG ratio checker.
2. Set browser zoom to 200 percent and confirm text enlarges with nothing clipped, truncated, or obscured (the W3C F69 test).
3. Narrow the viewport to 320 CSS pixels, which equals 1280 pixels at 400 percent zoom, and confirm no horizontal scrolling for lines of text.
4. Apply Steve Faulkner’s Text Spacing bookmarklet (TPGi) or Alastair Campbell’s text adaptation bookmarklet, and confirm no text disappears or collides.
5. Search the CSS for font-size set in vw or vh, or capped by clamp() or max(). If found, repeat the zoom check at the browser’s maximum zoom.
6. Find images of text and canvas text, and confirm real text carries the same information.
7. Set Android to 200% font size (Android 14 and later) and iOS to its largest accessibility size, then look for clipped text.
8. Rescan with an automated tool such as WAVE after fixes, and repeat the manual steps each release.

Step 3 does not need a 1280 pixel window. A docked window at 960 pixels reaches 320 CSS pixels at 300 percent zoom, and W3C cares about the resulting viewport width, not the starting size.

Fold these steps into a wider web accessibility checklist so they run on every release.

Accessible Typography FAQ

Is Comic Sans accessible?

No study in the 2025 Ho Sang and Petrarca review singles it out as accessible. Comic Sans appears in just one reviewed study, a memory experiment (Diemand-Yauman et al., 2011).

Is all caps text bad for accessibility?

For body text, yes. Many studies report that all-uppercase text reads slower than sentence case (Dyson, 2023, cited by Ho Sang and Petrarca).

Short labels are a different case. Arditi and Cho (2007) found uppercase read faster at small sizes, especially by readers with vision loss.

Can I use bold and italic styles?

Yes, with limits. Use bold for headings and emphasis and keep italics rare, since Dyson and Beier (2016) found bold more effective than italics for headings.

Italics slowed reading in Slattery and Rayner (2010), and people with low vision often prefer bold (Bernard et al., 2013).

Do accessible type rules apply to email?

Yes. The Access Board’s Section 508 definitions list email messages as documents.

Section508.gov puts typical email text at 10 to 11pt or 13 to 15px, because readers control zoom.

Does dark mode change the contrast rules?

No. The ratios stay at 4.5:1 for text and 3:1 for large-scale text in every color theme.

Check each theme on its own, because SC 1.4.3 tests the specified foreground and background pair.

Do print and PDF documents follow the same typography rules as web pages?

Partly. Section508.gov puts document body text at 11 or 12pt, against 15 to 16px on the web.

SC 1.4.12 does not apply to PDF because the format is not markup, according to W3C. A PDF built to PDF/UA (ISO 14289) can still reflow for low-vision readers.

What to Fix First on a Site With Failing Text

Start with text contrast and text sizing, because both change a single declaration, not a layout.

After that, order the remaining work by cost and by who is blocked.

• Color tokens that fail contrast
• Font sizes in viewport units or capped by clamp()
• Containers that clip under spacing overrides

Template-level reflow comes last, since it demands the most layout work.

Sites serving EU customers face earlier legal exposure on spacing and reflow, because EN 301 549 version 3.2.1 includes both criteria while the Section 508 text does not.

The trade-off is design control. Removing fixed heights and size caps gives up pixel-exact layouts.

This order holds as of 11 October 2026. The contrast step changes only if WCAG 3.0 adopts a new algorithm, which its 10 September 2026 draft leaves undetermined.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026