Mac dark mode accessibility checklist for UI handoff
Keep two kinds of evidence: source foreground and background values for the formal contrast check, plus a rendered screenshot for the state people actually see.
A reliable Mac dark mode accessibility check uses two proofs. Record the owned foreground and background values from the design system, CSS, or app code and test that pair against the right criterion. Then inspect the same component in Dark Mode and keep a screenshot or observation note that shows its rendered state.
The source pair supports the formal result. The rendered view catches issues such as the wrong appearance token, unexpected transparency, a weak focus state, or a meaningful icon that disappears. A sampled screenshot pixel cannot recover every layer or prove which source values produced it.
Disclosure: I build TeenyApps, including TeenyColor and TeenyTool. They can support local sampling and pair checks, but the design system, app code, or browser inspector remains the source of truth.
Quick answer: use a two-proof record
| Evidence | What it answers | What to record |
|---|---|---|
| Owned source pair | Which foreground and background values should be compared? | Token or computed values, component and state, criterion, ratio, and result. |
| Rendered view | Did the intended appearance and state actually render? | Build or route, appearance settings, screenshot, observation, and sampled area if useful. |
| Decision | Is the state ready, or does it need a change? | Pass or issue, limitation, owner, and the next action. |
01Lock the appearance and component state
Set macOS Appearance to Dark for a deterministic review. An automatic appearance can switch during the session and make two captures look inconsistent. Record the app build or web route, window or screen, component, content, and interaction state before changing any color.
Include the relevant accessibility display settings. Apple's Dark Mode guidance calls for testing Increase Contrast and Reduce Transparency separately and together. Repeat a state when those settings change its background material, separator, label, control, or focus treatment.
Compare the same state in Light Mode too. The comparison can reveal a hard-coded color, missing semantic variant, or role that adapts in one appearance and stays fixed in the other.
02Proof one: test the owned source pair
Start with the foreground and the background that the product owns. For a solid web color, that may be a CSS token or a computed value. For a native app, it may be a semantic color resolved for the current appearance. Record the role names alongside the values so another person can trace the result back to code or the design system.
Transparency and layered materials need more care than two hex fields can provide. Use an appropriate browser or accessibility inspector to identify the effective background, or resolve the composite in the implementation. Document the assumption if a stable composite cannot be obtained.
TeenyTool accepts a foreground and background hex pair and shows AA and AAA rows for normal and large text. Its local source confirms the four thresholds. It does not choose the correct row, resolve opacity or gradients, identify text size, or inspect the interface for you.
03Choose the criterion before reading the result
| Content or state | WCAG 2.2 target | Important boundary |
|---|---|---|
| Normal text | 4.5:1 at Level AA; 7:1 at Level AAA | Use this row unless the text meets the large-scale definition. |
| Large text | 3:1 at Level AA; 4.5:1 at Level AAA | WCAG defines large scale as at least 18 point regular or 14 point bold, with equivalent sizes for other fonts. |
| Meaningful controls and graphics | 3:1 at Level AA against adjacent colors where Success Criterion 1.4.11 applies | Check the visual information needed to identify the component, state, or graphic. |
| Inactive control | Exempt from the contrast requirements in 1.4.3 and 1.4.11 | An exemption does not make an indistinguishable disabled state useful. |
| Keyboard focus | Visible focus is Level AA; Focus Appearance is a separate Level AAA criterion | Check visibility first, then apply the AAA area and 3:1 change requirements when that criterion is in scope. |
Also check whether color carries meaning by itself. A ratio result cannot prove that an error, selection, status, or chart series has another usable cue.
04Proof two: inspect the rendered state
Capture the same component and state used for the source record. A screenshot can show that the intended Dark Mode variant rendered and that nearby content, materials, borders, and focus treatment remain distinguishable. It is supporting evidence, not the formal color-pair record.
W3C cautions that screen-captured examples can lose resolution and should not be examined pixel by pixel as proof of sufficient contrast. Display scaling, color profiles, transparency, background materials, and text antialiasing can all affect sampled pixels. Avoid sampling a glyph edge or a blended boundary when the goal is to describe a flat rendered region.
TeenyColor uses the native macOS color sampler and converts the selected color to sRGB. It can keep the observation in local history, add a name, pin it, or export it. It cannot recover the original token, font size, layer stack, or intended semantic role from a pixel.
The companion guide explains how to check Dark Mode colors from Mac screenshots while keeping those limits visible.
05Run the paired appearance pass
- Open the exact component and state in Light Mode, then repeat in Dark Mode.
- Repeat Dark Mode with Increase Contrast enabled.
- Repeat Dark Mode with Reduce Transparency enabled when the interface uses translucent or material backgrounds.
- Enable Increase Contrast and Reduce Transparency together and check the same state once more.
- Review text, meaningful controls and graphics, color-only meaning, keyboard focus, errors, selections, hover or pressed states, and real content.
Use the same source roles throughout the pass. If an appearance setting resolves a semantic color to a different value, add that resolved pair to the record instead of overwriting the first result.
Dark mode handoff record
One row per component state keeps the decision reviewable. The handoff should contain:
- App build or web route, component, content, and interaction state.
- Appearance plus Increase Contrast and Reduce Transparency settings.
- Foreground and background role names, owned source values, and where those values came from.
- Applicable criterion, text size and weight when relevant, measured ratio, and result.
- Screenshot or rendered observation, including the sampled region when a pixel value is recorded.
- Known limitation, owner, decision, and next action.
A useful note is specific: “Build 42, account warning, Dark plus Increase Contrast, warning label token #F3B55A over panel token #24262B, normal-text AA result recorded, rendered state attached, focus treatment still needs review.”
What each local check can prove
| Check | Useful evidence | Limit |
|---|---|---|
| TeenyColor | Selected sRGB pixel from the rendered Mac screen, with local history and labels. | Does not identify the source token, layer stack, font properties, or accessibility criterion. |
| TeenyTool Contrast Checker | Ratio and four AA or AAA threshold rows for one foreground/background hex pair. | Does not resolve transparency, gradients, images, text classification, focus geometry, or color-only meaning. |
| Browser or accessibility inspector | Computed styles, element context, or platform accessibility information. | Coverage depends on the platform, implementation, and inspector. |
| Design system or app code | Owned role names, variants, and values intended to ship. | Still needs a rendered-state review to catch integration errors. |
Sources checked
- W3C Web Content Accessibility Guidelines 2.2, including the definitions and success criteria for contrast, use of color, focus visibility, and focus appearance.
- W3C Understanding Success Criterion 1.4.3: Contrast (Minimum), including the note about screen-captured examples.
- W3C Understanding Success Criterion 1.4.11: Non-text Contrast.
- Apple Human Interface Guidelines: Dark Mode.
- Apple Human Interface Guidelines: Color.
- TeenyColor and TeenyTool behavior was checked against each app's homepage and local Swift source on Aug 14, 2026.
FAQ
How do you check dark mode color accessibility on Mac?
Record the foreground and background values from the design or code, then inspect the same component in Dark Mode on the Mac. Keep the formal contrast result and the rendered screenshot observation as separate evidence, and repeat the check with Increase Contrast and Reduce Transparency when those settings affect the interface.
Can a screenshot prove WCAG color contrast?
No. A screenshot can show what rendered, but scaling, color profiles, transparency, materials, and antialiasing can change its pixels. Use the owned foreground and background values, or an appropriate browser or accessibility inspector, for the formal contrast result. Keep the screenshot as supporting visual evidence.
Does a passing contrast ratio make dark mode accessible?
No. A passing pair does not prove that color is not the only cue, that focus is visible, that meaningful controls and graphics meet the right criterion, or that keyboard and assistive technology behavior works. Treat contrast as one gate inside the full accessibility review.
Build the two-proof handoff record.
Keep the source pair, formal result, rendered observation, and remaining limitation together for each Dark Mode state.