Terminal Accessibility: Contrast, Size, and Fonts That Don't Fight You

Most terminal theme advice optimizes for how a screenshot looks. That is a legitimate goal — we build a skinnable terminal, we are not going to pretend otherwise — but it is a different goal from "I can read this at 5pm on a Friday after eleven hours."

The accessibility version of this conversation is usually framed as being for other people. It is not. Contrast requirements, comfortable sizes, and fonts that do not force you to disambiguate characters are things that make everyone faster, and the popular themes are frequently bad at all three.

Here is what actually matters, with numbers.

Contrast, and why your favorite theme probably fails

The number is a ratio between the text color and the background behind it. WCAG's AA threshold for normal-size body text is 4.5:1. AAA is 7:1. For large text, AA drops to 3:1.

Terminal text is small, dense, and read for hours. Treat 4.5:1 as the floor, not the target.

Now the uncomfortable part. Run a few of the popular schemes through a contrast checker and you find that the base foreground on the base background is usually fine — theme authors get that right. What fails is the ANSI palette on that background, and specifically:

Bright black / "dim" text. Comments, secondary output, timestamps, and the greyed-out text agents use for reasoning. This is routinely in the 2.5:1 to 3.5:1 range. It is the single most common accessibility failure in terminal themes, and it is applied to text you actually need.
Blue on dark. Standard ANSI blue is very dark. On a dark background it can land near 2:1, which is functionally invisible. Most good themes brighten it; some do not.
Yellow and green on light backgrounds. The mirror problem for anyone using a light theme.

You can check your own in a minute. Print the palette:

for i in {0..15}; do
  printf "\e[38;5;${i}m%3d ██ The quick brown fox\e[0m\n" $i
done

Anything you have to lean in for is a failure regardless of what the ratio says. But do check the ratio, because eyes adapt and you will normalize something bad.

The fix is not to abandon the theme. It is to override the two or three colors that fail — usually bright black and blue — and keep the rest. Every terminal lets you set the 16 ANSI colors independently of the theme. Color theory for terminal themes covers building a palette that holds together while you do that.

One more, specific to agent work: if your terminal renders a background image or gradient behind the text — which ours very much does — contrast is no longer one number. It varies across the window. The practical rule is that any skin with text over artwork needs a scrim: a semi-opaque layer between the art and the text. We build that into the skin format for exactly this reason, and it is the first thing to check on a community skin that looks great and reads badly. See the skinning docs.

Size, which nobody sets deliberately

Terminal font size defaults are historical accidents. 11pt or 12pt made sense on a 72dpi display in 1998.

On a modern Mac at a normal viewing distance, 14pt is a reasonable floor for sustained reading and 15–16pt is not indulgent. The instinct against this is that a bigger font means less on screen, which feels like less productivity. In practice, past a certain density you stop reading and start scanning, and scanning is where you miss the line that mattered.

Two things make larger text cheaper than it looks:

Line height. A little extra leading — around 1.2 — improves readability more per pixel than a font size bump. Dense terminal output with no leading is genuinely hard to track across long lines. If your terminal exposes line spacing, that is the cheapest legibility win available.

Letting the window be wide. 100–120 columns at 15pt on a modern display is fine. The 80 column convention is a punch card artifact.

More on the size question specifically in the best font size for coding.

Fonts that reduce work

The letterforms that cause problems in code are a short, well-known list: 1 l I, 0 O, rn versus m, and ; versus : at small sizes.

What to look for:

A slashed or dotted zero. Non-negotiable. Every good coding font has one; make sure yours is enabled, since some ship it as a stylistic set you have to turn on.
A distinguishable l. Either a tail or a serif. If l and 1 and I are three vertical strokes, you will misread hashes, IDs, and file paths.
Generous x-height. More pixels for the part of the letter that carries identity, which is what lets you drop a size and stay comfortable.

On dyslexia specifically, the honest position is that the evidence for specialized fonts is mixed — studies have not shown a consistent advantage for fonts marketed on that basis, and individual preference varies a lot. What does have support is increased character spacing and increased line spacing. Both are terminal settings, and both are worth trying before buying anything.

Two things to be careful with:

Ligatures. => becoming a single arrow glyph is lovely and it also merges two characters into one shape. Some people find that harder to parse, particularly when reading unfamiliar code. It is a preference, not an improvement, and it is worth turning off for a week to find out which you are. Coding ligatures explained covers the mechanics.

Thin weights. A Light or Thin weight at high contrast looks elegant in a screenshot and is measurably harder to read as body text. Regular or Medium.

Nerd Fonts for terminal covers installation and which families patch cleanly.

Motion, which is newer than the rest of this

This part is specific to the current moment, and it is worth saying plainly: agents produce a lot of animation. Spinners, progress bars, streaming text, status areas redrawing several times a second.

For people with vestibular sensitivity, that is not a neutral background. For everyone else it is still a persistent attention magnet in peripheral vision while you are trying to read something else on screen.

Practical mitigations:

Most agents have a quieter output mode or a way to reduce status rendering. Worth finding.
macOS's Reduce Motion in Accessibility settings is respected by well-behaved apps, including ours — animated skin effects and transitions honor it.
Keep purely decorative animation off in the session you read in, and save it for the one you show people. Per-session theming makes this easy rather than a global compromise.

The same argument applies to CRT-style effects, scanlines, and flicker. They are great, we ship them, and they belong in the terminal you demo from rather than the one where you read a 40,000-line transcript.

A checklist

Foreground on background is at least 4.5:1. Actually measure it.
Bright black / dim text clears 4.5:1 too. This is the one that fails.
ANSI blue is visible on your background. Override it if not.
Any skin with text over artwork has a scrim behind the text.
Font size 14pt or larger for sustained work.
Line height around 1.2.
Slashed zero on, l distinguishable from 1.
Regular or Medium weight, not Light.
Reduce Motion respected, decorative effects off in your reading session.

None of this requires giving up a theme you like. It is usually two color overrides, one size bump, and a line-height setting — twenty minutes, once.

MOLTamp is a skinnable terminal shell where every one of those is a per-session setting rather than a global compromise. Download it, read the skinning docs, or browse what other people have built in the community marketplace.