Desktop app ignores prefers-contrast (macOS Increase Contrast); dark-theme body text passes WCAG 2.x but falls below APCA body-text minimum

Summary

Long-form assistant output in the desktop app is hard to read for users with low vision, and the app offers no high-contrast escape hatch. Two concrete, measured findings:

1. The app does not respond to prefers-contrast or forced-colors at all. Extracting app.asar (v1.26832.0) and searching every shipped JS/CSS bundle returns zero occurrences of either media feature. macOS Settings → Accessibility → Display → Increase Contrast is silently ignored — the one OS-level lever a low-vision user reaches for does nothing here.

1. Chat prose renders in a text tier that passes WCAG 2.x but falls below APCA's body-text minimum. The dark-theme secondary tier (--text-300: hsl(50 9% 73.7%) on --bg-100: hsl(60 2.7% 14.5%)) measures 8.3:1 under WCAG 2.x — comfortably past AA and even AAA — yet scores Lc −65 under APCA-W3 (4g), below the |Lc| ≥ 75 body-text minimum and rated suitable for large/bold text only. The muted tier (--text-500) scores Lc −45. WCAG 2.x's ratio formula is known to be lenient on exactly this pattern (light grey on dark); APCA models it more accurately, which is why the app can tick the compliance box while long paragraphs still read as washed out.

So this is not "fails WCAG" — it doesn't. It's the combination of (a) large volumes of body copy set one tier down from primary, (b) a scoring model that under-penalises grey-on-dark, and (c) no way for affected users to opt into more contrast.

Measured values

Token definitions extracted from the shipped bundles (dark theme):

| Token | Value | WCAG vs bg-100 | APCA Lc | APCA verdict |
| --- | --- | --- | --- | --- |
| --text-100 (primary) | hsl(48 33.3% 97.1%) | 14.4:1 | −101 | body ✓ |
| --text-300 (secondary) | hsl(50 9% 73.7%) | 8.3:1 | −65 | large text only |
| --text-500 (muted) | hsl(48 4.8% 59.2%) | 5.4:1 | −45 | below body minimum |

Light theme is stronger (primary 17.5:1, secondary 10.4:1) but its muted tier sits at 4.6:1 — right on the AA floor.

Reproduction

1. npx @electron/asar extract /Applications/Claude.app/Contents/Resources/app.asar out/
2. grep -rE "prefers-contrast|forced-colors" out/ → no matches in any bundle.
3. Token values via grep -roE "--(text|bg)-[0-9]+:\s*[^;\"]+" out/; ratios computed with the WCAG 2.x relative-luminance formula and APCA-W3 0.0.98G-4g.
4. Visual confirmation: toggle macOS Increase Contrast — no change in the app.

Environment: Claude desktop 1.26832.0, macOS 26.5.2 (25F84), dark theme.

Suggested fixes, in order of impact

1. Honour prefers-contrast: more with a high-contrast token set (e.g. promote body copy to the primary tier and raise the muted floor). This alone makes the OS accessibility setting work as users expect.
2. Offer an in-app "higher contrast text" toggle for the same token swap, for users who don't know the OS setting exists.
3. Longer term: audit the dark-theme text tiers against APCA rather than WCAG 2.x ratios alone — the current palette is a textbook case of the two models disagreeing.

Context

Report prompted by a side-by-side comparison with another agent app whose body prose is near-white (~Lc 90+): the same content is materially easier to read there for a user with imperfect vision. Measurements in this report were made with Claude Code itself; happy to provide the extraction/measurement scripts if useful.