Cell background color and text color contrast issue for read-only cells

[laurali42]

• It's unclear which cells are editable and which are read-only. All cells have the same background color, but for read only some are displayed with a different colored text, and some with italicized text? And empty cell are harder to tell.

• The read-only gray text has contrast issue with the cell background color, it's hard to read and does not pass the contrast checker (see attached for dark mode colors checked). Please consider using a different text color to display read-only text.

[ww-mw]

Thanks @laurali42 — confirmed, with numbers. I measured this in Chromium against the shipped dist/webview bundle with VS Code's real --vscode-* palette injected, in both Dark Modern and Light Modern, on rows built from a real .sldd by the real data model. (Unit tests cannot answer this: happy-dom composites no alpha and evaluates no color-mix, so a half-transparent token measures as fully opaque there.)

Per the maintenance rules a contrast finding is a capture, not a fix — changing a design token reaches every view in the extension — so here is the measurement and the options.

Measured

element	theme	composited colour	on	ratio	WCAG
read-only text (.label.readonly, .readonly-cell)	Dark Modern	rgb(114,114,114)	rgb(24,24,24)	3.69	fails AA (4.5), passes AA-Large
read-only text	Light Modern	rgb(173,173,173)	rgb(248,248,248)	2.13	fails AA and AA-Large
editable control	Dark Modern	—	—	11.06	passes AAA
editable control	Light Modern	—	—	10.55	passes AAA

Both runs were clean — no console errors, no failed requests — so the ratios are real and not an unstyled table.

Light is far worse than Dark, which the report does not mention and is the headline: 2.13 fails even the large-text threshold. Editable text is ~5× the contrast of read-only text, so this is not a small imbalance.

Cause — a token that is 50% transparent

src/webview/vscode-theme.css:7:

--dex-color-text-muted: var(--vscode-disabledForeground, var(--vscode-descriptionForeground));

--vscode-disabledForeground is half-transparent by design: #CCCCCC80 in Dark Modern, #61616180 in Light Modern. Composited against the table background that gives the two colours above. It is VS Code's token for a disabled control — a thing you cannot interact with and generally do not need to read. We are using it for read-only data, which the user very much does need to read. That mismatch is the whole bug.

Also found: the cue is overloaded

Worth deciding at the same time, because the obvious fix interacts with it. In src/webview/components/dex-tree-table.ts, the muted colour currently carries four distinct meanings — a read-only name label (1072), a read-only cell (1078), a section header row (1085), and an object-valued cell (1094) — and italic carries three, including td.col-DataType (776), which is fully editable. So "faint and italic" does not reliably mean read-only today. And an empty read-only cell carries no cue at all, since colour is the only signal.

Options

(a) Point the token at --vscode-descriptionForeground (the one-line change). Measured: 6.55 Dark / 10.55 Light — both pass AA. The catch, and it is the reason this is not a silent fix: in Light Modern descriptionForeground equals foreground (both #3B3B3B), so read-only text becomes pixel-identical to editable text and the distinction disappears in the theme where it is currently worst. You would trade an unreadable cue for no cue.

(b) An explicit, opaque --dex read-only colour — derive it ourselves to hit ≥4.5 in both themes while staying visibly dimmer than body text (e.g. mixing foreground toward the background with a measured ratio rather than inheriting an alpha token). Fixes contrast and keeps the distinction. Costs a token we own and must maintain per theme kind, and needs a forced-colors check (@media (forced-colors) must not keep it dim).

(c) Stop carrying the meaning in colour alone — keep a mild dim, and mark read-only structurally (a lock affordance, a cursor/tooltip, or aria-readonly), freeing italic to mean one thing. Most robust and the only option that helps an empty read-only cell or a forced-colors user, but it is a visual-design change well beyond a token tweak.

I'd recommend (b) now, (c) later: (b) is a bounded, measurable fix for the failing ratio, and (a) should be rejected outright because of what it does to Light Modern. Happy to land (b) once someone signs off on the target ratio and how dim is dim enough — that is the judgement call I will not make at 2am.

Numbers are reproducible via the maintenance browser harness against the shipped bundle in both themes.

[ww-mw]

Addendum — the two high-contrast themes, measured in the same harness on 2026-09-18, which completes the picture for the decision:

theme	today (disabledForeground)	ratio	if pointed at descriptionForeground	ratio
Dark Modern	#CCCCCC80	3.69 FAIL	#9D9D9D	6.55 AA
Light Modern	#61616180	2.13 FAIL	#3B3B3B	10.55 AA
HC Black	#A5A5A5	8.53 AA	#FFFFFFB3	9.96 AA
HC Light	#7F7F7F	3.77 FAIL	#292929B3	5.32 AA

So three of the four default themes fail AA today, and the 50% alpha is not something a theme author chose — disabledForeground is #CCCCCC80 in VS Code's colour registry, not in any theme JSON, which is why no theme escapes it.

This does not change the recommendation above: descriptionForeground passes AA in all four, but in Light Modern it is #3B3B3B, i.e. identical to foreground — so option (a) buys AA everywhere at the price of read-only text being indistinguishable from editable text in Light Modern. That trade-off is the decision to make.