Improve chat text contrast and readability in dark mode

[samanthamsong]

Problem

Several text elements in Windows Companion chat have insufficient contrast in dark mode and are difficult or impossible to read. This may be an accessibility issue for users with low vision or reduced contrast sensitivity.

In the attached example, the following elements appear especially faint:

• The Assistant is thinking... status
• Message timestamp and model metadata
• Model, agent, and mode selector text
• Secondary text and controls near the message composer

Some controls look disabled even when they are available because their foreground color is too close to the dark background.

Screenshot

Expected behavior

• All essential text and interactive controls remain clearly readable in dark mode.
• Text and UI components meet applicable WCAG 2.2 contrast requirements, including at least 4.5:1 for normal text and 3:1 for large text and meaningful UI components.
• Enabled and disabled states are visually distinguishable without making enabled controls appear unavailable.
• Contrast remains sufficient across hover, focus, selected, loading, and disabled states.

Acceptance criteria

• Audit dark-mode foreground and background color combinations in the native chat surface.
• Correct the contrast of status text, metadata, selectors, composer text, and interactive icons.
• Add or update automated accessibility and theme tests for affected components.
• Verify keyboard focus indicators and screen-reader labels remain available after the visual changes.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 15, 2026, 4:38 PM ET / 20:38 UTC.

Summary
The screenshot establishes a credible readability problem, and current main does not establish a complete fix. The earlier theme refactor addressed different behavior; this collaborator-authored report remains necessary.

Reproducibility: unclear. the screenshot demonstrates the symptom, but its build and theme combination are unknown and no current-main Windows reproduction was run.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Confirm the current Windows theme combination and resolved text brushes, then separate the status/metadata defect from intentional disabled selectors before assigning a focused repair.

Review details

Best possible solution:

Use theme-aware text resources that follow the active chat surface, preserve intentional disabled states, and verify contrast, focus, and labels in dark-mode idle and generating states.

Do we have a high-confidence way to reproduce the issue?

Unclear: the screenshot demonstrates the symptom, but its build and theme combination are unknown and no current-main Windows reproduction was run.

Is this the best way to solve the issue?

Yes, a focused theme-resolution and contrast repair fits the existing accessibility contract; blanket brightening would be premature because some selectors are intentionally disabled during replies.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The screenshot’s build, Windows theme, and application theme preference are unspecified, leaving the exact current-main trigger unresolved.
• Treating every faint selector as enabled could accidentally change intentional active-reply disabling.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• remove issue-rating: 🦪 silver shellfish: Current issue advisory state no longer selects this label.

Label justifications:

• P2: The screenshot supports a bounded native-chat accessibility problem without establishing a blocked setup or unusable core workflow.
• impact:ux-friction: Faint status and metadata make chat activity difficult to read and interpret.

Evidence reviewed

What I checked:

• Screenshot inspected: The downloaded issue attachment visibly shows near-black thinking status and timestamp/model text on a dark background. Selector text is also faint, but the screenshot alone cannot establish whether those controls are enabled. Inspected proof-image-1.png from the supplied media manifest; the image does not identify its application build.
• Current timeline brush resolution: Thinking text and message metadata request TextFillColorSecondaryBrush. The shared Text helper resolves through BrushFor, which reads Application.Current.Resources and falls back to black. This identifies a concrete diagnostic path but does not establish which resource resolved in the screenshot. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:1077, 3c43751b2bac)
• Selectors have intentional disabled states: The chat root sets MessageOptionsDisabled during an active turn or pending queued send. Composer model and reasoning pickers consume that value through IsEnabled, so their generating-state appearance must be distinguished from enabled-control contrast. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:318, 3c43751b2bac)
• Existing accessibility contract: The repository defines real-process Axe.Windows scans as a WinUI quality gate and calls for focused validation of contrast-sensitive changes. Existing chat scans and theme-resource source tests do not by themselves demonstrate the reported dark-mode text pairs across interaction states. (docs/ACCESSIBILITY.md:3, 3c43751b2bac)
• Related merged work is not a demonstrated fix: refactor(chat): use Reactor theme resources #1084 (refactor(chat): use Reactor theme resources) replaced legacy accessibility observation and preserved High Contrast navigation. Its supplied proof concerns those paths, not the ordinary dark-mode text pairs reported here. Refactor duplicate helpers and brittle tests #756 (Refactor duplicate helpers and brittle tests) is a helper/test refactor, not a demonstrated contrast repair. (ff1901275a41)
• Main and release identity: The checkout matches the supplied fetched-main SHA, and v2026.9.4 points at that checkout. No separate fixed commit or later release was established. (3c43751b2bac)

Likely related people:

• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Scott Hanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.