Mac dark mode color QA checklist for UI handoff
Dark mode color QA is not a vibe check. Sample the rendered state, name the color role, test the real foreground/background pair, and write down the light, dark, and accessibility settings you checked.
A practical Mac dark mode color QA checklist starts with the screen people will actually use. Open the same component in light mode, dark mode, and any increased-contrast state you support. Then sample the real colors and check the actual pairs.
The goal is not to make every dark mode value look like an inverted light mode value. The goal is to make text readable, controls identifiable, focus visible, and UI states understandable when the appearance changes.
Disclosure: I build TeenyApps, including TeenyColor and TeenyTool. My bias is toward local checks because dark mode QA often uses unreleased screens, client screenshots, or private design tokens.
Quick answer
| Dark mode question | Local Mac check | Record in the handoff |
|---|---|---|
| Did the same state render in both appearances? | Capture or open the component in light mode and dark mode before sampling. | Screen name, state, appearance, and whether the value came from render or token. |
| Which color changed? | Sample foreground, background, border, icon, and focus-ring colors from the rendered UI. | Role name, light value, dark value, and source context. |
| Can people still read and understand it? | Check the exact foreground/background contrast pair, not just the accent color. | Ratio, AA/AAA result, text size assumption, and state tested. |
| Does the fix need a new color? | Use tints, shades, or a separate dark-mode variant after the failing state is known. | Chosen replacement, reason for change, and whether it needs design-system approval. |
01Start with rendered dark mode, not the token sheet
Design tokens matter, but dark mode bugs usually appear in rendered states. A background may shift when a sheet is raised. A separator can disappear against a tinted window. A disabled label can pass in the design file and fail after opacity is applied.
Apple's Human Interface Guidelines tell designers to make sure colors work in light, dark, and increased-contrast contexts, and to avoid hard-coded colors that do not adapt. That guidance is useful, but it still needs a screen-level QA pass.
Use TeenyColor when you need to sample the rendered value. Its source uses the native macOS color sampler, converts picked colors to sRGB, copies the selected format, keeps local history, and lets you name and pin important colors.
02Compare roles, not loose swatches
A dark mode pass gets messy fast if every value is just a swatch. Name the role before comparing values: primary button fill, primary button label, card background, popover background, focus ring, destructive text, disabled label, muted icon, border, chart line, selected row.
That role name catches false matches. A dark card background and a disabled label can both look gray in isolation. They are not interchangeable. If a color exists to communicate a state, do not review it as decoration.
The local workflow is simple: sample, name, pin, compare, then export only the values that belong in the review. The TeenyColor spoke for this cluster shows how to check dark mode colors from Mac screenshots without uploading private UI.
03Check the exact foreground and background pair
Dark mode contrast failures often come from checking the wrong pair. White text against black is easy. The real screen may use off-white text over a lifted panel, a translucent sidebar, a gradient, or a selected state with a tinted accent background.
WCAG 2.2 sets Level AA text contrast at 4.5:1 for normal text and 3:1 for large text. Non-text UI components and graphical objects have their own contrast criterion. Treat those numbers as gates, not as a guarantee that the entire state is accessible.
TeenyTool includes a local Contrast Checker for foreground/background pairs. When the right pair still fails, the TeenyTool spoke in this cluster explains how to generate tints and shades from a hex color before checking the candidate again.
04Test states that designers often skip
Default states get attention. The misses hide in hover, focus, selected, active, pressed, disabled, error, warning, success, empty, loading, and read-only states. Dark mode makes those misses more obvious because low-contrast neutrals have less room to breathe.
Check focus rings and meaningful borders separately. If a focus indicator is the only cue that a keyboard user has reached a control, it deserves its own contrast check. If a chart line, icon, or status dot carries meaning, do not bury it in a text-only pass.
Also test with real content. A placeholder row with three words can pass while a production row with names, numbers, icons, warnings, and truncation fails in the same component.
05Generate variants only after the problem is specific
A tint or shade tool is useful after you know what failed. It is not a substitute for identifying the role, state, and background. If the disabled label fails on a lifted dark panel, fix that pair. Do not generate a new palette because one state looked off.
In TeenyTool, the Tint & Shade Generator takes a base hex color and creates 10 tints toward white and 10 shades toward black. That is useful for exploring nearby UI state values before a designer or developer turns the chosen variant into a real token.
Keep the handoff honest: "tested dark mode selected row, foreground #EDEDED on background #1E2A38, AA pass, focus ring still weak" is more useful than "dark mode colors checked."
Dark mode QA checklist
- Open the same component in light mode and dark mode.
- When possible, repeat with increased contrast and reduced transparency settings that your audience may use.
- Sample the rendered foreground, background, border, icon, focus, selected, disabled, warning, and error colors.
- Name every color by role and state before copying or exporting values.
- Check exact foreground/background pairs for normal text, large text, controls, icons, borders, and focus indicators.
- Flag borderline passes and any state where color is the only cue.
- Use tints, shades, or new appearance variants only after the failing pair is known.
- Write down the source of truth: rendered screen, screenshot, design token, code token, or manual candidate.
What to use for each part
| Job | Use | Reason |
|---|---|---|
| Rendered value check | TeenyColor | Sample pixels from the real screen, name the value, pin it, and keep the evidence local. |
| Contrast gate | TeenyTool Contrast Checker | Test the exact foreground/background pair against AA and AAA thresholds. |
| Variant exploration | TeenyTool Tint & Shade Generator | Generate nearby light and dark candidates from a known hex value after the problem is specific. |
| Final source of truth | Design system or app code | Only the owned token system or codebase should decide what ships. |
Sources checked
- TeenyColor claims were checked against the TeenyColor homepage and local Swift source for native sampling, sRGB conversion, pasteboard copy, local history, pinned colors, custom names, and palette export.
- TeenyTool claims were checked against the TeenyTool homepage and local Swift source for color tools, contrast checking, tints, shades, and local utility coverage.
- Apple Human Interface Guidelines: Dark Mode.
- Apple Human Interface Guidelines: Color.
- Apple Human Interface Guidelines: Accessibility.
- W3C WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum).
- W3C WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast.
FAQ
How should you QA dark mode colors on Mac?
Open the real screen in dark mode, sample the rendered foreground and background colors, name each color by role and state, check the exact contrast pair, then document whether the value came from the rendered UI or the design source.
Should dark mode colors be inverted from light mode?
No. Dark mode colors should be designed and tested as their own appearance variants. Apple recommends adaptive colors and light and dark variants for custom colors rather than hard-coded values that do not adapt.
Does passing WCAG contrast make a dark mode UI finished?
No. A contrast pass is a useful gate, but a dark mode review also needs state checks, focus visibility, color-only meaning checks, increased contrast testing, and real content in the interface.
Check dark mode colors before handoff.
Use TeenyColor to sample rendered colors locally. Use TeenyTool to check contrast and explore tints or shades when a state needs a safer variant.