There is no official list of accessible fonts. WCAG, the ADA, and Section 508 do not name a required typeface or a minimum font size. What they do set are rules about how text behaves: it has to resize to 200%, survive wider spacing, reflow on a narrow screen, and meet contrast ratios. A plain sans-serif such as Arial, Verdana, or Atkinson Hyperlegible at 16px (1rem) or larger, with 1.5 line height and 4.5:1 contrast, is the safest starting point on phones, tablets, and desktops.
This guide covers the fonts that hold up on real devices, the WCAG success criteria that actually apply to typography, and how to test both before you ship.
What WCAG Actually Requires for Fonts
Most "ADA font" advice skips the source. Here is what the standards say. WCAG 2.1 Level AA is the benchmark the Department of Justice adopted for state and local government websites under ADA Title II, and it is what most ADA website claims are measured against. Section 508 points to WCAG 2.0 Level AA. AODA in Ontario also uses WCAG 2.0 Level AA.
- 1.4.4 Resize Text (AA): text can be resized up to 200% without assistive technology and without losing content or function. Fixed pixel heights on containers are the usual cause of failures.
- 1.4.12 Text Spacing (AA, added in WCAG 2.1): nothing breaks when a user sets line height to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times.
- 1.4.10 Reflow (AA, added in WCAG 2.1): content works at a width of 320 CSS pixels without scrolling in two directions. This is the rule that catches cramped mobile layouts.
- 1.4.3 Contrast (Minimum) (AA): 4.5:1 for normal text and 3:1 for large text, which WCAG defines as 18pt (about 24px) or 14pt bold (about 18.66px).
- 1.4.5 Images of Text (AA): use real text instead of text baked into images, so users can resize and restyle it.
The official wording lives in the WCAG 2.1 specification, and Section508.gov's fonts and typography guidance covers the federal side. Notice what is missing: no rule says "use Arial." The font is your choice, as long as the text passes these checks.
The Anatomy of a Readable Font
A font can look clean in a design review and still fail when real users hit a checkout form at 200% zoom. Choose by structure, not taste. Before you approve a typeface, check these traits:
- Large x-height: taller lowercase letters hold their shape at common UI sizes.
- Open spacing: letters need room to stay distinct on dense mobile screens.
- Clear character differences: type I, l, 1, 0, and O side by side. If they blur together, people will misread codes, prices, and passwords.
- Steady stroke weight: hairline weights fade first on bright or low-quality screens. Regular and medium weights survive more conditions.
- Open counters: the inner spaces of a, e, o, and p should stay visible at body size.
Fonts that struggle on screens tend to share the opposite traits: thin strokes, decorative terminals, compressed widths, and tight default spacing. A condensed display face can work in a large heading. It rarely works in body copy, form labels, or buttons.
For the vocabulary behind these checks, see the WebAbility.io glossary entry on readable content.
A short visual explainer helps when you review fonts with non-design stakeholders:
7 Accessible Fonts for Web and Mobile Devices
You don't need dozens of options. You need a short set that survives real screens, real zoom, and real content.
1. Arial
Arial is still one of the safest defaults for body text and interface copy. It ships on almost every operating system, so it renders predictably and needs no font download.
2. Verdana
Verdana was designed for screens. Its wide letterforms and generous spacing make it a strong choice for forms, dashboards, and small labels. It takes more horizontal room, so test it in tight components.
3. Tahoma
Tahoma is a narrower relative of Verdana. It stays readable in buttons, menus, and compact UI where Verdana would wrap.
4. Helvetica
Helvetica works for navigation and product UI, but only in regular or heavier weights. The light and thin weights are where teams get into trouble. Its I and l are also easy to confuse, so avoid it where users type or read codes.
5. Atkinson Hyperlegible
The Braille Institute designed Atkinson Hyperlegible for readers with low vision, with extra care to make commonly confused characters look different. It is a free download and a good pick for settings screens, transactional flows, and public-service sites.
6. OpenDyslexic
OpenDyslexic uses weighted letter bottoms meant to help some readers with dyslexia. Readers' preferences vary, so offer it as an option people can switch on rather than forcing it on every visitor.
7. APHont
APHont was developed by the American Printing House for the Blind for low-vision readers. It suits portals and reading-heavy services where clarity matters more than brand expression.
Quick comparison
| Font | Strength | Best use |
|---|---|---|
| Arial | Familiar, renders everywhere | Body text, forms, general UI |
| Verdana | Wide, very clear letterforms | Mobile UI, dense labels, dashboards |
| Tahoma | Compact but readable | Buttons, menus, tight components |
| Helvetica | Clean structure in regular weights | Navigation, headings |
| Atkinson Hyperlegible | Distinct similar characters | Low-vision readers, transactional flows |
| OpenDyslexic | Dyslexia-oriented letter shapes | Optional user preference |
| APHont | Built for low vision | Reading-heavy services |
How to choose fast
- Body copy: Arial, Verdana, or Atkinson Hyperlegible.
- App UI: Tahoma, Arial, or carefully tested Helvetica.
- User options: offer Atkinson Hyperlegible or OpenDyslexic as a reading mode.
- Brand headings: keep the brand font for headings only if body text stays on a readable companion face.
Sizing, Spacing, and Contrast in Code
Font accessibility has to survive implementation. The brand font gets approved, the mockup looks polished, and the live product still ends up hard to read on phones because text was locked to fixed sizes.
Set a scalable baseline
Browsers default to 16px, so start body text at 1rem and size everything else in relative units. That lets browser zoom and operating system text settings work, which is what 1.4.4 Resize Text expects.
html { font-size: 100%; }
body {
font-family: "Atkinson Hyperlegible", Arial, Verdana, sans-serif;
font-size: 1rem;
line-height: 1.5;
font-weight: 400;
color: #111;
background: #fff;
}WCAG has no minimum font size, so 14px body copy is not an automatic failure. It is a riskier default, though, and it leaves less room before text gets hard to read. Keep 16px for anything people need to read carefully, like instructions, prices, and error messages.
Use spacing that survives zoom and reflow
- Line height: about 1.5 for body text, about 1.2 for headings.
- Letter spacing: small adjustments only. Too much breaks word shapes.
- Paragraph spacing: clear gaps between blocks so scanning stays easy.
- No fixed heights: let buttons, cards, and inputs grow with their text, or 1.4.12 Text Spacing will fail.
Then check the page at 200% zoom and at a 320px-wide viewport. If headings crash into buttons, helper text overlaps inputs, or cards crop content, the type system isn't ready. For more implementation detail, see our guide to accessible font size and font style.
Put contrast in your design tokens
Contrast belongs in tokens and component specs, not in a final polish pass. Normal text needs 4.5:1. Watch the usual problem spots: light gray help text, placeholder text used as the only label, and small text inside brand-color buttons. Our guide to color contrast for accessibility walks through each ratio.
Test on Real Devices, Then Let Users Adjust
Type that passes on a designer's laptop can still fail on the screens your visitors use. Include these in your test pass:
- A high-density phone: check thin weights, small labels, and muted text.
- An older or lower-quality display: watch whether letters lose definition.
- Zoom and OS text size settings: confirm menus, forms, and cards still work.
- Real content lengths: short placeholder copy hides wrapping problems.
Manual checks catch rendering problems. An automated scan catches the repeatable ones across every page, such as low-contrast text and missing labels. Run a free scan with the WebAbility website accessibility checker to see where your pages stand.
No team can tune type for every vision condition and screen. A solid default plus user controls covers far more people. WebAbility.io lets visitors switch on dyslexia-friendly fonts, scale text, raise contrast, and save personal profiles, so you don't have to hand-build every preference.
Font Licensing and Advanced Questions
How should teams think about font licensing?
System fonts like Arial, Verdana, and Tahoma need no web license and no download. For commercial fonts, read the actual terms before launch. A desktop license often does not cover web embedding, apps, or self-hosting.
Are variable fonts good for accessibility?
They can be. One file can give you precise control over weight and width. They can also drift, because it is easy to pick a very light weight or squeeze the width axis. Document the allowed weight and width ranges for body text, labels, and buttons, then enforce them in code review.
What about icon fonts and fallback stacks?
SVG icons are usually more predictable than icon fonts, which show stray characters when they fail to load. For text, always define a fallback stack, such as font-family: "Preferred Font", Arial, Verdana, sans-serif;, so a blocked or slow font drops to another readable sans-serif.
Frequently Asked Questions
Is there a list of ADA-approved fonts?
No. The ADA does not approve or ban specific fonts. For websites, ADA claims are usually measured against WCAG 2.1 Level AA, which sets rules for resizing, spacing, reflow, and contrast but leaves the typeface up to you.
What is the minimum accessible font size?
WCAG sets no minimum font size. It requires that text can be resized to 200% without breaking. In practice, 16px (1rem) body text is the common baseline because it is the browser default.
Are sans-serif fonts more accessible than serif fonts?
Not by rule. WCAG doesn't prefer either. Simple sans-serif faces are a common recommendation for screens because their shapes stay clear at small sizes, but a well-spaced serif in a readable weight can also work. Test with your real content.
What is the best font for dyslexia?
There is no single answer. Many readers do well with clear sans-serif fonts that have distinct letters and generous spacing, like Verdana or Atkinson Hyperlegible. Dyslexia-specific fonts such as OpenDyslexic help some people and not others, which is why they work best as an option the reader picks.
Do the same rules apply on mobile devices?
Yes. WCAG applies to web content on any device. Reflow at 320 CSS pixels and text spacing are the criteria most likely to fail on phones, so test both at your narrowest breakpoint.
Which ADA Title II deadlines apply to government websites?
The Title II rule requires state and local government websites to meet WCAG 2.1 Level AA, with compliance dates of 26 April 2027 for larger entities and 26 April 2028 for smaller ones and special districts. Typography is part of that review: resize, spacing, reflow, and contrast all apply.
The Short Version
Pick a readable sans-serif, set body text at 1rem with 1.5 line height, keep contrast at 4.5:1 or better, and never lock text into fixed-size boxes. Then test on real phones at 200% zoom and let users adjust what you can't predict. If you want to know where your site stands today, scan it with the free WebAbility checker.
