Audit every jedit theme for legibility

[flyingrobots]

Reported from live use.

Some shipped themes are unusable. The second theme in the list — a light mode — renders text that cannot be read at all.

Task

Audit every theme in src/ui/jedit-themes.ts against real rendered surfaces, not palette swatches in isolation. Use the color-expert skill for the evaluation.

Each theme needs, at minimum:

• Body text vs background contrast at a stated WCAG ratio, on every surface it is used on (editor, gutter, drawers, command line, footer, notifications, selected/active rows)
• Selection and cursor visibly distinct from both the text and the background
• Syntax highlight roles distinguishable from one another and each legible against the background
• Dimmed/inactive chrome still readable, not merely present

Deliverable

• A per-theme report: measured contrast ratios and pass/fail per surface
• Fixes for every failing theme, or removal of themes not worth repairing
• A spec that asserts minimum contrast for the tokens that matter, computed from the theme definitions, so a new theme cannot ship unreadable

[flyingrobots]

Theme legibility audit — all 8 themes

Measured WCAG 2.x and APCA Lc across every surface, chrome, gutter and markdown token, against each token's own background rather than a nominal one.

Body text (editor surface)

#	Theme	Mode	Contrast	Verdict
1	graphite	dark	15.20	AAA
2	morning	light	13.30	AAA
3	monokai	dark	13.94	AAA
4	solarized-dark	dark	12.25	AAA
5	solarized-light	light	4.13	FAIL
6	dracula	dark	13.36	AAA
7	nord	dark	9.25	AAA
8	catppuccin	dark	11.34	AAA

One theme fails, and it is the light one you could not read. Seven are AAA.

Worth flagging a correction to the report: you described it as "the second one". The second theme is morning, also light, and it measures 13.30 — AAA, among the best in the set. The unreadable one is solarized-light at position 5.

The cause is upstream fidelity, not an error

Solarized specifies base00 (#657b83) as light-mode body text on base3. That pair is 4.13:1 by construction — Schoonover designed Solarized around a fixed lightness relationship, not a contrast target. The theme is faithfully implemented; the source specification is what fails AA.

Options within the palette, on base3:

base0   #839496   2.93
base00  #657b83   4.13   <- was here
base01  #586e75   4.99   <- moved here
base02  #073642  12.05
base03  #002b36  13.92

base01 is Solarized's own "emphasized content" ink, so AA is reachable without inventing a colour or leaving the palette.

Fixed in 403fb23

solarized-light body text    4.13 -> 4.99   FAIL -> AA
solarized-light current line 4.39 -> 4.51   FAIL -> AA

The current-line band needed a second nudge: Solarized's base2 highlight is darker than base3, leaving 4.39:1 against the new ink. Lifted 20% toward base3 (#f1ebd8) — the smallest change reaching AA while still reading as a distinct tinted band.

spec/theme-legibility.spec.mjs now holds body text and the current line to AA for every theme. Both assertions fail before the change.

What I deliberately did not enforce

Gutter tokens run 3.0–4.2 in several themes (dracula, monokai, nord, morning). That is defensible for secondary chrome — the gutter is meant to recede — and WCAG treats non-text and large-text at 3:1. Raising it would flatten the intended hierarchy. Recording rather than changing.

chrome.titleLogoShadow and titleSceneFar are the lowest numbers in every theme (down to 2.48). They are a drop shadow and a depth-cued background. Auditing a shadow as if it were body text is a category error, so I excluded them. They appear in the raw data below only for completeness.

Remaining question for you

Should the gutter get its own floor, lower than body text but explicit — say 3:1 — so it cannot silently drift into invisibility? Related: #317, where gutter dimming is expressed purely as ANSI SGR 2 and is invisible on terminals that ignore faint. A gutter floor and that decision are the same conversation.