Dark Mode Testing Checklist (2026)

Dark Mode Testing Checklist (2026)

Dark Mode Testing Checklist (2026)

A practical, item‑by‑item guide for verifying that an application behaves correctly when the system or app‑level theme switches to dark mode. This checklist groups more than thirty concrete verification points into happy‑path, error/edge, accessibility, security/privacy, performance, and release‑readiness buckets. Each item includes a clear pass criterion, a real‑world example, and notes on how manual or automated techniques (including autonomous exploration) can cover it in a single pass.

Dark Mode Testing Checklist (2026): Happy Path

System‑level vs App‑level Theme Switching

When the operating system toggles between light and dark themes, the app must react without a restart. Verify that:

1. Theme propagation – All UI components (activity/fragment, view hierarchy, web view, custom canvas) receive the new theme values within 200 ms of the system broadcast.
2. Persisted preference – If the app stores a user‑chosen override (e.g., “Always dark”), the stored value survives process kill and device reboot.
3. Consistent fallback – When a resource lacks a dark‑mode qualifier, the app falls back to the light version *only* after explicitly checking for the qualifier; missing fallbacks produce hard‑coded colors that break contrast.

*Example*: A messaging app uses ?attr/colorSurface for card backgrounds. In dark mode the attribute resolves to #121212. If a developer hard‑coded #FFFFFF in a layout, cards appear as white blocks on a dark background, failing the moment after a theme switch.

Core UI Elements

Check every visible element for correct color assignment:

*Example*: A settings screen uses a SwitchCompat whose thumb color is defined via ?attr/colorControlActivated. In dark mode the thumb becomes a bright cyan (#00E5FF). Verify that the thumb remains distinguishable from the track (#424242) and does not bleed into adjacent items.

Navigation and Transitions

Dark mode must not break navigation patterns:

• Bottom navigation bar – Icons and labels switch colors; the selected item’s background uses a semi‑transparent overlay (#66FFFFFF in light, #66000000 in dark).
• Drawer/menu – The scrim behind the drawer should be #66000000 in dark mode (instead of #66FFFFFF).
• Page transitions – Fade or slide animations must not reveal a flash of the light theme; ensure the window background is set to the dark color before the animation starts.

*Example*: An e‑commerce app uses a shared‑element transition from a product list to a detail page. If the shared element’s background is not updated before the transition starts, a white rectangle briefly appears over the dark detail screen, which is perceptible as a flicker.

Forms and Input Controls

Every editable field must retain legibility and correct state indication:

• Hint/text‑input label – Uses ?attr/colorHint (light: #9E9E9E, dark: #FFFFFF at 38 % opacity).
• Error underline – Should be #B00020 (light) and #CF6679 (dark) – a red that stays visible against dark backgrounds.
• Auto‑fill suggestions – The suggestion list background must follow ?attr/colorSurface; text color follows ?attr/colorOnSurface.
• Password visibility toggle – The eye icon must invert correctly; verify that the toggle does not disappear when the field is focused.

*Example*: A login screen shows a floating label that turns red when validation fails. In dark mode the label color must shift from the light‑mode red (#B00020) to the dark‑mode red (#CF6679). If the app forgets to update the label’s textColor state, the error message appears as a dark gray that users may miss.

Media Playback and Overlays

Video players, image galleries, and overlay dialogs must adapt:

• Player controls – Play/pause, seek bar, and full‑screen icons use ?attr/colorOnSurface for icons and ?attr/colorSurface for the control bar background.
• Subtitles – Text should be white with a black outline or semi‑transparent black background (#99000000) to stay readable over both bright and dark video frames.
• Toast/Snackbar – Background uses ?attr/colorSurface; text uses ?attr/colorOnSurface. Ensure the snackbar action button text color changes appropriately.

*Example*: A news app displays a video with subtitles. In dark mode the subtitle background is #99000000. If the background is omitted, white text on a bright frame becomes washed out, while on a dark frame it is legible but lacks the required contrast ratio of 4.5:1 for normal text.

Dark Mode Testing Checklist (2026): Error and Edge Cases

Empty and Loading States

Empty lists, loading spinners, and error pages often receive less attention in dark mode.

• Empty state illustration – Verify that any vector assets used in the illustration have a dark‑mode variant or are tinted with ?attr/colorOnSurface.
• Spinner color – Should use ?attr/colorControlActivated; confirm it does not stay the light‑mode blue (#2196F3) in dark mode.
• Error message background – Typically a soft red (#FFEBEE light, #4A1414 dark). Ensure the background does not clash with the surrounding surface color.

*Example*: A settings screen shows an empty state with a robot illustration and the text “No preferences saved”. If the illustration is a static white SVG, it appears as a ghostly shape on the dark surface, reducing recognizability.

Dynamic Content and Theming

Content fetched from a server may carry its own color information (e.g., HTML emails, markdown rendered in a WebView).

• HTML email rendering – Inline styles must respect the CSS prefers-color-scheme media query; otherwise, force a light theme inside the WebView leading to contrast issues.
• Markdown rendering – Code blocks often have a hard‑coded light background (#F5F5F5). Replace with a theme‑aware background or add a CSS rule that switches based on the system theme.
• Chat bubbles – Sender bubble uses ?attr/colorPrimary; receiver bubble uses ?attr/colorSurface. Verify that the bubble’s tail (often a nine‑patch) does not expose a hard‑coded color.

*Example*: A chat app renders incoming messages with a light‑gray bubble (#E0E0E0). In dark mode the bubble should switch to a dark surface (#2F2F2F). If the app forgets to update the background drawable, the message appears as a light rectangle, making it hard to differentiate from the sender’s bubble.

Edge‑case UI States

Certain UI states only appear under specific interactions (long press, swipe, rotation).

• Contextual action mode – The action bar background should follow ?attr/colorSurface; text and icons use ?attr/colorOnSurface.
• Long‑press highlight – The ripple or highlight color must be defined via ?attr/colorControlHighlight; verify it does not stay the light‑mode teal (#00BCD4).
• Rotation‑triggered layout changes – Some apps load alternative layouts (e.g., landscape‑only) that may lack dark‑mode resources. Confirm that both portrait and landscape variants have the full set of -night qualifiers.

*Example*: A photo editor shows a toolbar that appears only in landscape. The toolbar’s background is defined in layout-land/toolbar.xml without a -night variant. When the user rotates to landscape while dark mode is active, the toolbar stays light, causing a sudden flash.

Animations and Motion Effects

Animations can inadvertently expose the wrong theme during intermediate frames.

• Fade‑in/fade-out – Ensure the animated view’s background is set to the final theme color before starting the animation; otherwise, a brief flash of the opposite theme appears.
• Scale‑based reveal – For a FAB that expands into a menu, the menu’s background must be ready before the scale animation begins.
• Lottie or vector animations – If the animation file contains embedded color layers, provide a dark‑mode version or use android:tint to recolor at runtime.

*Example*: A splash screen uses a Lottie animation with a white logo. In dark mode the logo should be tinted to #FFFFFF via lottieView.setValueCallback(...). Forgetting to apply the tint results in a white logo on a white background (if the splash background is also white) or a low‑contrast logo on a dark background.

Dark Mode Testing Checklist (2026): Accessibility

WCAG Contrast Ratios

Automated contrast checkers (axe-core, Google’s Accessibility Scanner) should be run on every screen in both themes.

• Normal text – Minimum 4.5:1 contrast against its immediate background.
• Large text (18pt+ or 14pt bold) – Minimum 3:1 contrast.
• UI components (icons, buttons) – Minimum 3:1 contrast for interactive elements.

*Pass criterion*: No violations reported by the chosen tool under either theme.

*Example*: A settings toggle’s thumb is #FFFFFF on a track #424242. Contrast = 5.2:1 → passes. If the thumb were #CCCCCC, contrast drops to 2.8:1 → fails.

Screen Reader Compatibility

TalkBack (Android) and VoiceOver (iOS) must announce state changes correctly when the theme switches.

• State description – Ensure that switches, checkboxes, and radio buttons announce “checked” or “unchecked” with the correct tonal cue (e.g., “switch on” vs “switch off”).
• Live regions – Error messages that appear via android:accessibilityLiveRegion="polite" must be spoken regardless of theme; verify that the spoken text does not rely on color cues (“the red field is invalid”).

*Example*: A form field shows an error icon (red circle) and an error message. The TalkBack label for the field should be “Password, invalid, enter at least eight characters”. If the label only says “Password, invalid” without describing the visual cue, users who cannot perceive color miss the severity.

Focus Order and Visibility

Keyboard or switch‑device navigation must retain a visible focus indicator.

• Focus highlight – Use ?attr/colorControlFocus (light: #2196F3, dark: #64B5F6). Verify the highlight is at least 2 dp wide enough padding.
• Avoid hidden focus – Some custom views override onDraw and skip drawing the focus rectangle; test with a switch device to ensure the focus never disappears.

*Example*: A custom chip component draws its background as a rounded rect but omits the focus outline. When navigating with a D‑pad, the chip does not show any visual change, causing users to lose track of focus.

Touch Target Size

Dark mode does not change the physical size of touch targets, but low‑contrast targets can be harder to locate.

• Minimum size – 48 dp × 48 dp (or 24 dp with adequate spacing).
• Contrast of target boundary – If the target uses a subtle border, ensure the border color contrasts with the surface at least 3:1.

*Example*: A floating action button with a 1‑dp white border on a dark surface (#121212) yields a contrast of ~15:1 → passes. If the border were #424242, contrast drops to ~3.5:1, still acceptable but borderline; consider increasing the border width or using a brighter tint.

Reduced Motion and Animation Preferences

Users who have enabled “Remove animations” or “Reduce motion” should not be bombarded with motion that can trigger discomfort.

• Animator duration – Respect android:windowAnimationScale set to 0; animations should either skip or run at a negligible duration (< 10 ms).
• Motion‑based cues – Do not rely solely on motion to convey state (e.g., a button that only jiggles when disabled). Provide a static visual cue (color or opacity change).

*Example*: A toggle switch uses a wiggle animation to indicate an error. When “Reduce motion” is on, the wiggle is disabled, leaving only the color change. If the color change is insufficient (low contrast), users may miss the error. Ensure the error state also changes the thumb’s opacity or adds an icon.

Dark Mode Testing Checklist (2026): Performance and Resource Usage

GPU Overdraw

Dark themes often reduce overdraw because dark backgrounds absorb less light, but overdraw can still occur due to multiple translucent layers.

• GPU Overdraw tool – Enable “Show GPU overdraw” in Developer Options; aim for no more than 2× overdraw (light blue) on any screen.
• Layer count – Use the “Profile GPU rendering” tool to spot excessive layers (e.g., nested frames, unnecessary ViewOverlay).

*Example*: A news feed uses a card with a semi‑transparent overlay (#66000000) for a gradient title background. In dark mode the overlay is still semi‑transparent black, causing the card to be drawn three times (background, overlay, text). If the overlay is unnecessary, removing it reduces overdraw from 2.5× to 1.5×.

Battery Impact

On OLED screens, dark pixels consume significantly less power. Measure the actual power draw to confirm the benefit.

• Battery Historian – Record a typical user scenario (e.g., scrolling a list for 5 minutes) in both light and dark themes; compare the mA draw.
• Frame rate – Ensure the UI maintains at least 60 fps (or 90 fps on high‑refresh devices) in dark mode; dropped frames can increase power due to GPU throttling.

*Example*: A video streaming app shows a bright thumbnail grid. Switching to dark mode reduces the average power draw from 320 mA to 260 mA during idle scrolling, a ~19 % saving that translates to longer battery life.

Memory Consumption

Dark‑mode resources (e.g., -night drawables) should not cause duplication that bloats APK size.

• APK Analyzer – Verify that for each resource with a -night qualifier, there is a corresponding light resource; avoid storing identical copies under both qualifiers (use aliasing).
• Runtime memory – Use Android Studio’s Memory Profiler to ensure that loading a dark‑mode screen does not cause a sudden spike due to large bitmap decoding (e.g., a full‑screen background image that is unnecessarily high resolution).

*Example*: An app ships a 2048 × 2048 px background for both light and dark themes, differing only by a color overlay. By using a single base image and applying a color filter (ColorFilter) at runtime, the APK size drops by 1.4 MB.

Frame‑rate Stability During Theme Switch

Switching themes at runtime should not cause a noticeable jank.

• Choreographer frame callbacks – Record frame timestamps before and after issuing AppCompatDelegate.setDefaultNightMode(). Ensure no frame exceeds 16 ms (for 60 Hz) or 11 ms (for 90 Hz).
• UI thread work – Avoid heavy work (e.g., JSON parsing, bitmap decoding) on the UI thread during the theme change; move it to a background thread or use postDelayed.

*Example*: A settings screen loads a large XML preference file when the theme changes, causing a 45 ms frame drop and a perceptible stutter. Moving the file parse to an AsyncTask eliminates the jank.

Dark Mode Testing Checklist (2026): Security and Privacy

Screenshot Obfuscation

Some apps hide sensitive data in screenshots (e.g., banking apps) by overlaying a tint. The overlay must work in both themes.

• FLAG_SECURE – Verify that the window flag is set; the resulting screenshot should be blank regardless of theme.
• Custom overlay – If the app draws a semi‑transparent rectangle (#99000000) over sensitive views, ensure the alpha value provides sufficient obscuration in dark mode (the underlying dark surface may already be low‑brightness, making the overlay less effective).

*Example*: A payment app overlays a black rectangle with 60 % opacity over the CVV field. In light mode the overlay makes the field unreadable. In dark mode the same overlay yields a dark gray over a dark background, still obscuring but slightly less; increase opacity to 80 % for dark mode or use a contrasting color (#FFFFFF with 30 % opacity).

Theme‑based Side‑Channel Leaks

An attacker could infer the current theme via timing or power analysis, potentially revealing UI state.

• Constant‑time rendering – Ensure that drawing operations do not branch on theme values in a way that creates measurable timing differences (e.g., loading a different image set based on theme).
• Cache partitioning – If the app caches bitmaps separately for light and dark themes, an attacker with cache‑side‑channel access could deduce which theme is active. Consider using a single cache with runtime tinting instead.

*Example*: An app loads a high‑resolution hero image (hero_light.png or hero_dark.png) based on the theme. An attacker monitoring memory allocation spikes could infer the theme. Switching to a single asset with a ColorFilter removes the timing variance.

Credential Field Visibility

Password fields must not reveal characters via accidental contrast tricks.

• Letter spacing – Some apps increase letter spacing to make passwords easier to read; verify that the spacing does not create a visual pattern that leaks character width in screenshots.
• Show/hide toggle – The eye‑icon toggle must not leave a residual ghost of the password when toggled quickly; test with rapid toggles to ensure the text is cleared or obscured correctly.

*Example*: A login screen shows the password as black dots (•••••). In dark mode the dots are rendered as white circles (◯◯◯◯◯). If the dot drawable is not swapped, the white circles may blend into a light‑colored background behind the field (if the background is incorrectly light), making the password guessable.

Dark Mode Testing Checklist (2026): Release Readiness

Continuous Integration (CI) Integration

Automated checks should run on every pull request to catch regressions early.

• Screenshot diff – Use a tool like Shot or Papaki to render each screen in both themes and compare against a baseline; fail the build if the perceptual difference (e.g., SSIM < 0.95) exceeds a threshold.
• Lint rules – Enforce that no color resources are hard‑coded (#RRGGBB) in layout XML; instead they must reference ?attr/ or a theme‑aware color resource.
• Accessibility tests – Run axe-core-android or Google Accessibility Test Framework as part of the unit test suite; treat any WCAG AA violation as a build failure.

*Example*: A CI pipeline runs ./gradlew connectedAndroidTest which executes a set of UI tests that capture screenshots of the login, home, and settings screens in both light and dark modes, then runs diffy to compare against approved baselines. Any new screen that lacks a -night variant triggers a failure because the diff exceeds 0.02 RMSE.

Baseline Screenshot Management

Maintaining a reliable baseline is essential for detecting unintentional changes.

• Version‑controlled baselines – Store approved screenshots in a Git LFS folder (tests/screenshots/baseline/). Tag each baseline with the app version and the Android API level.
• Automated baseline update – Provide a script (./gradlew updateBaselines) that, when invoked with a special flag (-PupdateBaselines), replaces the baseline with the current run’s screenshots after manual review.
• Ignore list – Exclude screens that are known to be flaky (e.g., those that depend on network‑generated content) or that contain dynamic elements like timestamps; replace those areas with a mask before comparison.

*Example*: The home screen contains a “Last updated: xx:xx” timestamp. Before comparison, a mask rectangle is placed over the timestamp area, ensuring that changes in the timestamp do not cause false positives.

Regression Script Generation

Leverage the exploratory data captured by autonomous testing tools to generate repeatable scripts.

• Appium (Android) – The tool can output a JSON description of each tapped element, scroll direction, and input text. Convert this to Appium Java/JavaScript tests that assert the presence of theme‑specific colors via getAttribute("background").
• Playwright (Web) – For hybrid apps or web views, export a Playwright script that sets prefers-color-scheme: dark via page.emulateMedia({ colorScheme: 'dark' }) and then validates CSS computed colors.

*Example*: After a SUSA run, the agent produces a file dark_mode_flow.json. A small Node script reads each step, generates a Playwright test that: 1) navigates to the URL, 2) forces dark mode, 3) checks window.getComputedStyle(element).getPropertyValue('background-color') matches the expected dark‑mode token, and 4) repeats for light mode.

Cross‑device Matrix

Dark mode rendering can differ across manufacturers due to theme overlays or OLED vs LCD panels.

• Device farm – Run the checklist on at least three representative devices: a stock Pixel (pure Android), a Samsung One UI device (custom theme overlay), and a Xiaomi MIUI device (deeply themed system UI).
• Theme override – Verify that forcing AppCompatDelegate.setDefaultNightMode(MODE_NIGHT_YES) overrides any OEM theme and yields consistent colors across devices.

*Example*: On a Samsung device, the system UI applies a dark overlay with a slight blue tint (#1A237E) to status bar icons. An app that uses ?attr/colorOnSurface for status bar icons receives the correct tint (#FFFFFF) after the override, ensuring consistency.

Release Notes and Documentation

Communicate dark‑mode support clearly to users and internal stakeholders.

• In‑app toggle description – If the app offers a manual toggle, describe it as “Follow system setting” or “Always dark”.
• Help center article – Include a screenshot pair (light/dark) for each major screen, with callouts showing where colors change.
• Release notes – Mention “Dark mode now fully supported on all screens, with WCAG AA contrast compliance verified”.

*Example*: The release notes for v3.2 read: “Dark mode has been extended to the chat composer, settings, and payment flow. Contrast ratios have been audited and meet WCAG AA standards. A new system‑follow option lets the app automatically match the OS theme.”

Leveraging Autonomous Exploration for Dark Mode

How an Autonomous Agent Covers Most of the Checklist

Platforms like SUSA (SUSATest) explore an app without pre‑written scripts by simulating a variety of user personas. When configured to test both light and dark themes, the agent implicitly validates many checklist items.

Configuring Personas for Dark Mode

SUSA ships with built‑in personas (curious, impatient, novice, adversarial, elderly, accessibility, power user, etc.). To stress‑test dark mode, enable the following combinations:

• Accessibility persona + dark theme – Tests TalkBack, large fonts, and reduced motion simultaneously.
• Adversarial persona + dark theme – Attempts rapid taps, long presses, and edge swipes to surface hidden UI states that may only appear under stress.
• Elderly persona + dark theme – Uses increased touch target size simulation and slower input speeds to verify that low‑contrast elements remain perceivable.

The agent’s configuration file (susatest-config.yaml) can include:

test_sessions:
  - name: dark_mode_accessibility
    theme: dark
    personas:
      - accessibility
      - elderly
    metrics:
      - contrast
      - talkback_feedback
      - frame_time
  - name: dark_mode_adversarial
    theme: dark
    personas:
      - adversarial
    actions:
      - long_press
      - rapid_tap
      - rotate_device

Interpreting Results

After a run, SUSA outputs a JSON report with sections for each persona. Key fields to inspect for dark‑mode compliance:

• theme_consistency: Boolean indicating whether all observed colors matched the dark‑mode token set.
• accessibility_violations: List of axe‑core warnings (e.g., contrast failures).
• frame_jank_max: Maximum frame duration observed during theme switches.
• screenshot_leak_detected: True if any screenshot captured non‑blank pixel data from a FLAG_SECURE window.
• generated_scripts: Paths to the Appium and Playwright test files that can be checked into the repo.

A typical pass criterion for a release build is:

• theme_consistency == true
• accessibility_violations.length == 0
• frame_jank_max <= 16 (for 60 Hz)
• screenshot_leak_detected == false

If any of these fail, the report highlights the exact screens and actions responsible, allowing developers to fix the specific issue before merging.

Practical Checklist Summary

Below is a condensed, copy‑paste‑ready checklist that you can paste into a ticket or a Wiki page. Each item includes a Pass/Fail column for quick marking during test sessions.