# Check a dark mode template beyond the homepage preview

By HTMLPick
Published: 2026-10-03
Updated: 2026-10-03

Review a dark mode template on the pages and states your visitors use. A dark homepage preview does not show whether forms, menus, and supporting pages remain readable. Compare the same task in each supported theme.

This article describes a manual review. It does not certify the accessibility of a listed template.

## Define how the theme is selected

Identify whether the template uses a fixed theme, the visitor's system preference, or an explicit website control. Those are different behaviors.

The [MDN prefers-color-scheme reference](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/prefers-color-scheme) explains how CSS can detect a requested light or dark theme. A website control needs its own behavior for any explicit choice.

Check the first visit, an explicit selection, and a later visit. Record whether the site preserves the choice. If the site offers a system option, check what happens when the operating system preference changes.

Do not describe a fixed dark design as a complete theme switch. Use the candidate's actual behavior in the comparison record.

## Review text against its real background

Check body text, navigation, supporting labels, and error messages. Review text over images separately from text on a plain surface.

The [W3C contrast guidance](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) gives minimum ratios of 4.5:1 for normal text and 3:1 for large text. The criterion defines large text and includes specific exceptions. A large-looking heading alone does not establish which threshold applies.

Measure the actual foreground and background combination. A color pair that passes on a card may fail over a photograph or a different surface.

Keep the result scoped to the text you reviewed. A passing pair does not establish complete accessibility conformance for the site.

## Follow the control through its states

Use the keyboard to reach a link, button, disclosure, and form input. Identify the active control in both themes. Open a menu and inspect the content inside it.

Check error, disabled, selected, and focused states where they exist. A button's ordinary state can work while its disabled label becomes unreadable. An error needs an explanation as well as a color change.

Use the [accessibility checklist](/guides/website-template-accessibility-checklist) for the wider initial review.

## Inspect images and brand assets separately

Place the actual logo and content images into each theme. A transparent logo designed for a light surface can disappear on a dark background. A photograph may already contain a white border.

Record whether an asset needs a theme-specific version or a stable surrounding surface. Keep the rights and source for each version.

Check product screenshots and charts with labels. Their own background and text can remain important even when the surrounding page changes theme. Do not invert all image colors as a general solution.

## Include supporting pages and external content

Review the article page, contact form, missing-page state, and any account or commerce page in the required scope. Templates can apply theme rules unevenly across those areas.

Check embedded content independently. A third-party widget may control its own theme. Record that limitation when the main visitor task depends on the widget.

Use this review record:

| Area | Condition | Evidence |
| --- | --- | --- |
| Preference | First visit and explicit choice | Theme behavior and saved state |
| Text | Every important text role | Actual foreground and background pair |
| Controls | Focus, error, selected, disabled | Readable state and usable action |
| Images | Actual logo, photograph, chart | Useful content in both themes |
| Supporting pages | Article, form, and missing page | Complete task in each theme |

## Keep theme changes within shared rules

Inspect whether the template uses shared color roles or repeated page-specific values. Shared roles make a later correction easier to apply consistently.

Use the [customization article](/blog/customize-website-template) to plan the change. Repeat the [real content review](/blog/test-template-with-real-content) after changing fonts, surfaces, or image frames.

Choose a template from the [directory](/templates) whose supported themes complete the required tasks. Record any remaining theme limitation before publication.