Color Scheme Preference

Introduction

The DeviceHub Color Scheme Preference tool is a free online prefers-color-scheme reporter, without installing theme debuggers, without claiming to fix every site’s dark mode, and without presenting appearance settings as clinical or medical diagnoses. Designers verifying that macOS Auto appearance reaches Safari and Chrome, engineers debugging color-scheme meta and CSS variables, QA capturing whether a bug reproduces only in dark mode, educators teaching @media (prefers-color-scheme: dark), and support teams separating “user chose dark OS” from “site hard-codes white” all open one HTTPS page and read the scheme the browser exposes. DeviceHub states limits plainly: prefers-* reflect OS and browser settings, not all assistive technology configurations, not every in-app WebView policy, and not a substitute for WAVE, axe, or professional audits. This page does not rewrite third-party CSS, does not diagnose vision conditions, and does not replace Color Blindness Test educational simulations under Display. Pair with Color Contrast Checker to validate light and dark token pairs with WCAG 2.x sRGB math. Pair with Accessibility Preferences when users also request more contrast. Pair with Forced Colors Test when High Contrast overrides themes. Pair with Accessibility Preferences for a hub snapshot. Pair with Reduced Motion Check when dark marketing pages also ignore motion preferences. Permissions stay none. Never claim a light/dark readout proves WCAG conformance for an entire product, and never frame scheme preference as an eye exam. Dark-mode quality is still an authoring problem: DeviceHub can prove the browser sees prefers-color-scheme: dark while a hard-coded white stylesheet ignores it, and that split is exactly what support tickets need documented with browser name, OS appearance, and any browser-level theme override. Theme switches that only toggle a class without listening to matchMedia will disagree with this page, capture both. Scheduled Auto appearance that flips at sunset produces “works in the morning, fails at night” bugs; always note local time beside the readout. In-app WebViews for banking or social apps frequently force a brand light chrome regardless of OS dark mode, unsupported or mismatched results inside those shells are capability evidence, not proof DeviceHub is broken. Never present light versus dark as an eye examination, cataract screening, or workplace vision certificate; DeviceHub accessibility tools remain informational, not medical or clinical diagnoses. Never claim a scheme readout replaces WAVE, axe, Lighthouse accessibility categories, or a professional audit of structure, names, and keyboard access. Pair deliberately with Color Blindness Test under Display when stakeholders need educational simulation of confusion pairs on both themes, still not clinical screening, and with Display Contrast Test when OLED auto-brightness washes mid-tones independently of CSS variables.

What this tool does

Color Scheme Preference queries prefers-color-scheme, shows light versus dark (and related supported values when the engine exposes them), and explains how authors typically gate CSS variables and color-scheme properties. It does not flip other websites, does not write OS appearance registries, and does not upload theme telemetry to DeviceHub for ads. Guidance covers browser overrides that disagree with the OS, scheduled Auto modes that change mid-demo, and why a dark OS plus a forced light site theme still shows dark in this tool while the site looks white. Typed permissions remain none. Side notes send users to Color Contrast Checker for hex ratios and to Color Blindness Test for educational simulation, not clinical diagnosis. Closing the tab ends the session. Notes remind teams that forced-colors can supersede decorative dark themes on Windows. The page may also call out how color-scheme CSS and meta color-scheme hints influence native form controls, scrollbars, and UA chrome, while reminding you that DeviceHub is not rewriting those UA styles on third-party origins. It clarifies that “dark” preference plus forced-colors active can produce system palettes that look nothing like your carefully authored dark tokens, open Forced Colors Test when Windows Contrast themes are involved. It encourages dual-theme QA matrices: light tokens through Color Contrast Checker, dark tokens through Color Contrast Checker again, then scheme preference as environment context. It does not rate aesthetic taste, does not download third-party theme packs, and does not infer health status from appearance settings. When browsers expose only light/dark without additional experimental values, DeviceHub reports what exists rather than inventing media features. Refresh after toggling OS Auto schedules so the capture matches the moment under test. Educators can project the page beside a live site to show students the difference between preference detection and theme implementation, two jobs, one honest toolkit.

When to use it

Use when shipping dual themes, when bugs appear only after sunset Auto switches, when documenting QA matrices for light/dark, when teaching color-scheme CSS, and when users report “your dark mode ignores my OS.” Prefer Color Contrast Checker for AA math on each theme. Prefer Forced Colors Test for High Contrast conflicts. Prefer Accessibility Preferences for multi-feature captures. Avoid treating scheme as medical advice. Avoid expecting DeviceHub to enable dark mode on arbitrary domains. Retest after browser appearance settings, after extension theme engines, and inside WebViews. Reach for Color Scheme Preference during design-token migrations from single-theme to dual-theme systems, when legal pages must remain readable in both appearances, when email HTML is out of scope but the marketing site is not, when documenting Storybook backgrounds against real OS settings, and when a PM asks “did we test dark mode” and needs environment proof rather than a shrug. Prefer Accessibility Preferences when you also need reduced motion and contrast rows in one screenshot for a release checklist. Prefer Accessibility Preferences when the user complaint is “I need stronger contrast,” which is related to but not identical with dark scheme. Prefer Keyboard Focus Test when dark themes remove focus rings that were only visible on light gray. Prefer Speech Synthesis Test when building read-aloud that must remain usable regardless of theme, still not a clinical speech exam. Avoid using scheme preference as a substitute for photographing every route; SPA shells can theme-switch per route. Avoid filing medical HR forms from a dark/light badge. Retest after browser updates that change default appearance inheritance and after users install “force dark” extensions that paint over sites without changing prefers-color-scheme.

How it works

prefers-color-scheme is a CSS media feature commonly resolving to light or dark based on user/OS settings. DeviceHub reads it with CSS/matchMedia and displays the result locally. Typed permissions stay none. Engines may honor browser-specific overrides above the OS. Meta color-scheme and CSS color-scheme affect form controls and UA styles, this page reports preference, not every UA chrome detail on third-party sites. Secure HTTPS hosting applies. Preference is not a full AT inventory. Professional audits still needed for structure and keyboard access. No DeviceHub upload of scheme for advertising. Low-entropy fingerprinting possible; share qualitative notes when enough. Not a clinical tool. Under the hood, authors typically combine prefers-color-scheme media queries with CSS custom properties, sometimes mirrored by a manual theme toggle stored in localStorage that can intentionally override the OS. DeviceHub reports the media feature the engine exposes to CSS; it does not read your localStorage theme key on other origins. That distinction prevents false confidence when a site’s toggle says dark while the OS, and this page, still report light, or the reverse. Secure HTTPS hosting keeps the diagnostic consistent. Typed permissions stay none in DeviceHub’s PermissionKind union. Fingerprinting via color scheme is low entropy compared with canvas hashes, yet public dumps of full preference hubs still deserve minimization. Professional auditors will still check focus order, alternate text, captions, and ARIA, none of which appear in a scheme media query. Wide-gamut and HDR displays can make dark theme grays look lifted; that is display color management, not proof the media query is wrong, pair with Display category tools when panels are the suspect. Compared with Color Contrast Checker, scheme preference does not compute WCAG 2.x relative luminance; run both. Compared with Color Blindness Test, scheme preference does not simulate dichromacy; keep educational simulation clearly labeled non-clinical. Compared with Forced Colors Test, system high-contrast palettes can override decorative dark themes entirely, document platform variance rather than accusing DeviceHub of lying about dark mode.

Step-by-step instructions

1. Open Color Scheme Preference over HTTPS on the browser under test.
2. Record light or dark as reported; note any browser appearance override.
3. Toggle OS appearance if needed, refresh, and confirm the page updates.
4. Validate theme tokens with Color Contrast Checker; check Forced Colors if High Contrast is involved.
5. Capture Accessibility Preferences for a broader prefers-* snapshot.
6. Label results as browser-visible scheme preference, not a medical finding and not a full accessibility audit.

Common problems

Browser override disagrees with OS. Auto schedule flips mid-call. Site ignores preference while DeviceHub correctly shows dark. Confusing scheme with contrast preference. Treating readout as WAVE replacement. WebView hard-coded themes. Extension theme engines. Claiming clinical vision results. Mixing Color Blindness Test empathy with diagnosis. Dark theme tokens that fail AA. Forgetting to retest both schemes before launch. Assuming prefers-* covers every AT. Filing tickets without timestamp for Auto mode. Force-dark extensions repaint pages without updating prefers-color-scheme, so DeviceHub shows light while the site looks inverted. Safari Intelligent Tracking or content blockers unrelated to scheme confuse testers who change too many variables at once. Electron shells and kiosk browsers ship fixed themes. Assuming dark mode automatically meets AA fails when muted purple text sits on charcoal. Claiming the tool diagnosed night blindness or other clinical conditions. Using a single homepage screenshot as dual-theme certification for checkout flows. Mixing Color Blindness Test empathy exercises into medical paperwork. Forgetting that print stylesheets may ignore dark preferences. Expecting DeviceHub to enable dark mode on pdf.js or canvas games. Filing WAVE replacement tickets from a scheme badge alone. Auto sunset flips during a live demo without anyone noticing the clock. Browser appearance set to Light while OS is Dark, DeviceHub correctly follows the browser. WebView hard-coded light brand chrome on Android. Designers testing only macOS while Windows users run High Contrast instead of dark scheme.

Privacy explanation

Color Scheme Preference reads a media feature available to CSS on any site and shows it locally. DeviceHub does not upload appearance settings for advertising when you use this page. Permissions stay none. Informational only, not medical or clinical. Clear shared classroom machines after demos if appearance was changed. Color Scheme Preference exposes a media feature already readable by any stylesheet on the web. DeviceHub does not upload appearance settings for advertising profiles when you use this page. Permissions stay none. Screenshots of the hub may reveal workplace laptop policies, share carefully. Informational accessibility environment data only: not a medical record, not a clinical diagnosis, not fitness-for-duty documentation. After classroom sessions, restore shared machines to the organization’s default appearance so the next class does not inherit an unexpected dark desktop.