Use the same comparison frame
- 01
Select a small set
Open the Gallery with the Theme filter, then use search, catalog numbers, and categories to keep a small review shortlist.
- 02
Switch each verified preview
Toggle each Gallery card between light and dark without changing the evaluation criteria.
- 03
Trace differences to tokens
Open the release detail and Token Lab to distinguish a deliberate semantic change from a favorable preview crop.
- 04
Shortlist before installing
Treat comparison as a selection aid. Installation still requires release-specific artifact verification.
Review interface roles, not isolated swatches
- Read primary and secondary labels over base, raised, and overlay backgrounds.
- Check that borders separate adjacent surfaces without becoming the strongest element.
- Keep brand, error, success, and warning roles distinguishable in both modes.
- Inspect the sidebar against the content canvas and raised cards.
- For Full Skins, verify that the runtime screenshot shows the final generated CSS and same-origin assets, not a Studio simulation.
Open the evidence tools
Check an actual reading session
Preview the same conversation, code block, menu, and input in both modes. Check selected text, secondary labels, warnings, and keyboard focus rather than judging only the large background.
Compare this palette in light and dark using a long conversation and a code block. Identify hard-to-read text and unclear focus states, then propose specific color adjustments.Common questions
Before you make a change
Answers about formats, compatibility, evidence, and rollback.
What does this guide verify?
This guide covers: Verified catalog specimens; Light and dark token pairs; System-mode runtime boundary
What should I do first?
A theme is not one screenshot. It is a coordinated pair of semantic token states that must remain legible across the DSH interface.
Which boundary matters most?
Inside DSH, system follows the operating-system color preference and resolves to light or dark. It is not a third token set and should not be simulated by editing page attributes.
Does contrast alone prove accessibility?
No. It is one check. Keyboard interaction, focus, labels, zoom, responsive layout, and reduced-motion behavior also need review.
Continue learning
Continue from the verified evidence
Compare published artifacts or return to the installation documentation.