Feature request: Dark mode beta

[erklu]

Background

Several users work with Sunet Scribe for extended periods of time, often reading and editing long transcriptions or subtitle files. A dark mode could reduce eye strain and improve usability in low-light environments.

A first test using the default dark mode support in NiceGUI showed that a naive theme switch results in poor readability and visual noise. A proper dark mode therefore requires deliberate design work rather than a simple toggle.

Scope and intention

This feature request proposes introducing dark mode as an optional, beta feature, with a strong focus on readability, accessibility, and editor usability.

Dark mode should be treated as a parallel visual theme, not as an inverted light mode.

Design principles

• Prioritise long-form reading and editing, not visual flair
• Use a dim dark theme, not pure black backgrounds
• Maintain clear visual hierarchy between content, metadata, and controls
• Avoid high-contrast white-on-black combinations
• Use accent colours sparingly and consistently
• Ensure compliance with WCAG 2.1 AA contrast requirements

Functional requirements

• Users can toggle dark mode on/off (per user, persisted preference)
• Dark mode is clearly marked as beta
• No functional differences between light and dark mode

UI areas in scope (initial)

• Dashboard / My files view
• Fulltext editor
• Subtitle editor

Other views (admin, onboarding, etc.) may be included later.

Editor-specific requirements

Fulltext editor

• Slightly elevated background compared to surrounding UI
• Clear distinction between:
  • Active paragraph
  • Inactive paragraphs
  • Speaker labels and timestamps (secondary text)
• Selection and cursor visibility must remain clear

Subtitle editor

• Clear visual separation of subtitle blocks
• Character counters must remain readable
• Warning states (approaching/exceeding limits) must not rely on colour alone

Accessibility requirements

• Colour must not be the only indicator of state (errors, warnings, selection)
• Icons and/or text labels must complement colour usage
• Contrast ratios must be verified for:
  • Primary text
  • Secondary text
  • Interactive elements
  • Error and warning states

Technical considerations

• Define explicit design tokens (CSS variables) for colours instead of relying on default theme inversion
• Avoid hardcoded colours in components
• Allow editor views to have dedicated tokens if needed
• Base implementation on NiceGUI theming, but override defaults where necessary

Non-goals (initial)

• No automatic OS-level theme switching
• No custom themes beyond light/dark
• No redesign of layout or interaction patterns

Acceptance criteria

• Dark mode can be enabled without degrading readability
• Editors remain comfortable to use for long sessions
• No loss of accessibility compared to light mode
• Users can safely ignore dark mode if they prefer light mode