Dark Mode Feedback Board: How to Design and Test One
A dark mode feedback board is a public ideas board, and the widget that opens it inside your product, that renders in a dark color scheme. It should follow the visitor's device setting by default, let them override it, and stay readable in both themes. Getting this right is mostly a design-system problem, not a styling one: define colors by role, test the awkward states, and make sure the widget matches the app that hosts it.
This guide covers what dark mode means for a board and a widget, how to choose between auto and a toggle, how to keep colors consistent, which accessibility checks matter, and how to test it.
TL;DR
- Support both: follow the user's operating system theme by default, and offer a manual override with a way back to "auto".
- Define colors as semantic tokens (text, surface, border, accent) with a light and a dark value, never as scattered hex codes.
- Check contrast in both themes: 4.5:1 for normal text, 3:1 for large text and interface components, plus visible focus rings.
- Test on real devices, switch themes mid-session, and walk full journeys: post an idea, vote, comment, read the roadmap.
- Treat feedback about the dark theme like any other feature request: put it on the board and let people vote.
Table of Contents
- What dark mode means for a feedback board and a widget
- Auto, manual toggle, or both
- Build the theme from semantic tokens
- Accessibility checks that matter in both themes
- Our point of view
- How to test dark mode properly
- Collecting feedback about the dark theme itself
- Where Petĩra fits
- FAQ
- Sources
What dark mode means for a feedback board and a widget
A feedback board is a small product of its own. It has a list of ideas, vote buttons, comment threads, status labels (under review, planned, in progress, shipped), a roadmap view, forms, empty states, and email notifications. Dark mode touches every one of those, not just the page background.
The widget is a different problem. It sits inside someone else's page, usually in an iframe or a panel, and has to look like it belongs there. If your app is dark and the widget pops up bright white, it reads as broken, even when everything works. The reverse is just as jarring: a dark panel over a light app.
So "dark mode" for this category really means three things:
- The public board looks right in both themes on its own URL or custom domain.
- The widget matches the host page's theme, not just the visitor's device setting.
- Everything around them, such as status badges, vote counts, images and email notifications, holds up in both.
Boards are also read by people on phones at night, in meetings, and on shared screens. Many people only discover the board when a link lands in a chat. A first impression that blasts a white page at someone who set their phone to dark is a small but real cost, and it is one you can avoid.
Auto, manual toggle, or both
The short answer is both. Honor the visitor's operating system preference by default, and give them a way to override it, with a clear option to return to "auto".
Why "auto" comes first
Browsers expose the device preference through the prefers-color-scheme media feature, which has been available across browsers since January 2020 according to MDN. Your board's stylesheet can read it and switch palettes with no JavaScript and no stored setting. It also reacts when someone's phone flips to dark at sunset, which a hard-coded theme never will.
Why you still need an override
Some people run a dark system and prefer a light reading surface for long text. Others have the reverse. A toggle respects that. The detail teams miss is the way back: if a toggle saves "dark" forever, a user who later changes their device setting sees no effect and may not know why. Offer three states (auto, light, dark) and make auto the default and the reset.
For the widget: sync the setting, not the color
If your app has its own theme switch, the widget should receive the setting ("light", "dark" or "auto") rather than a resolved color. Passing the setting lets the widget resolve the color itself, and it avoids the flash where a light default renders for a moment before the real preference is applied. The pattern is simple:
| Situation | What the widget should do |
|---|---|
| Host app passes "auto" | Follow the device theme and react to changes |
| Host app passes "light" or "dark" | Use that theme regardless of device |
| Host app passes nothing | Fall back to the device theme |
| Storage unavailable (private browsing) | Fall back to the device theme, never fail |
One more browser detail helps embedded content: declaring the color scheme your page supports lets the browser render built-in controls such as form fields and scrollbars in matching colors, which saves you from a white scrollbar beside a dark list.
Build the theme from semantic tokens
The most common cause of a patchy dark mode is color decisions made one element at a time. Someone darkens the background, then discovers a hard-coded gray border that vanishes, a vote button that glows, and a status badge that is unreadable.
The fix is to stop naming colors by appearance and name them by job. GitLab's dark mode rollout playbook recommends semantic design tokens that express intent and carry a value for both light and dark contexts, instead of isolated hard-coded colors, covering roles such as text, icons, borders and surfaces.
For a feedback board, a workable token set looks like this:
| Token | Used for |
|---|---|
surface-page | Page background |
surface-card | Idea cards, comment boxes |
text-primary / text-muted | Titles, body text, timestamps |
border-subtle | Dividers between ideas |
accent | Vote button, links, primary action |
status-planned, status-progress, status-shipped | Status badges |
focus-ring | Keyboard focus outline |
Each token gets a light value and a dark value. The component code only ever references the token. Switching themes then means swapping one set of values, and a new component inherits both themes without extra work.
Practical rules for dark palettes
- Avoid pure black and pure white together. A near-black surface with slightly softened text is easier to read for long comment threads.
- Desaturate accents. A vivid brand color that works on white often vibrates on dark. Keep a separate dark value for the accent.
- Use elevation, not shadows. Shadows disappear on dark surfaces. Slightly lighter card surfaces show hierarchy better.
- Check images and logos. User avatars and uploaded screenshots with white backgrounds will glow. A subtle border or rounded container tames them.
- Keep status colors distinct and labeled. Never rely on color alone, as covered below.
Where your own branding comes in
If you run your board on your own domain, the board should feel like part of your product. On Petĩra, custom domains and custom CSS are available, so you can map your brand accent and surface colors onto the board and keep both themes consistent with your app. Define your dark values as carefully as the light ones, since custom CSS is exactly where hard-coded colors sneak back in.
Accessibility checks that matter in both themes
Dark mode is often sold as an accessibility feature, but it can easily make things worse. Low-contrast gray on charcoal looks elegant in a mockup and fails real readers. Run the same checks in both themes, every time.
Contrast
WCAG AA asks for 4.5:1 contrast for normal text and 3:1 for large text. Interface parts have their own requirement: the non-text contrast criterion (1.4.11) requires essential visual information, such as the boundaries of a button or input, to meet 3:1 against adjacent colors. For a feedback board, that means the vote button outline, the comment field border, and the checkbox states all need checking in dark mode, not only the text.
Muted text is where boards fail most often: timestamps, vote counts, "posted by" lines. Test those first.
Focus rings
Keyboard users need to see where they are. WCAG 2.2's focus appearance criterion describes an indicator at least as large as a 2-pixel perimeter with a 3:1 contrast change between focused and unfocused states. A ring that works on white may disappear on a dark card. One robust approach is a two-color focus indicator, which stays visible on any background and saves you from writing per-background rules that are slow to maintain and easy to miss.
Don't rely on color alone
The WCAG quick reference says color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing an element. On a board, that applies to status badges: "Planned" and "Shipped" should carry text or an icon, not just a green or blue tint. Voted state should be more than a color change, for example a filled arrow plus an updated count.
Native controls
If you use progress bars or form controls, the CSS accent-color property lets you tint them with your brand color while the browser picks a contrasting color for the parts drawn on top. Trusting the browser here is usually safer than hand-tuning every state.
Our point of view
We build a feedback board for product teams, and the pattern we see is that dark mode gets treated as a cosmetic switch at the end of a project. It is not. A board is where your customers tell you what they want, and anything that makes it harder to read, vote or comment quietly reduces the quality of the signal you collect.
Our view is simple. Default to the visitor's device setting, because it costs them nothing. Let them override it, because preferences differ. Keep the widget matched to the host app, because a mismatch makes your whole product look unfinished. And treat the board's colors as part of your brand, defined once in tokens and applied through the custom CSS and domain settings your board already supports.
We also believe the board should stay boring in the best way: unlimited users, ideas and votes on every plan, so you never have to ration participation to control a bill. A theme should not change who can take part either. Every idea, vote and status needs to be as readable at 11 p.m. on a phone as at 10 a.m. on a desktop.
— Aron
How to test dark mode properly
A screenshot of the first screen proves little. BrowserStack's guide to testing dark mode recommends real Android and iOS devices, multiple browsers and operating systems, and checks on contrast, text, layout, images, icons, borders, theme switching and complete user journeys.
Translated to a feedback board and widget, a practical test plan looks like this.
1. Run the core journeys in each theme
- Open the board from a link, as a first-time visitor.
- Search for an existing idea and open it.
- Vote, remove the vote, and vote again.
- Post a new idea with a title, description and an attached screenshot.
- Comment, then edit or delete the comment.
- Open the roadmap and filter by status.
- Open the widget from inside the host app and submit a request.
Watch for white flashes between pages, unreadable placeholder text, and modals that ignore the theme.
2. Switch themes mid-session
Change the device setting while the board is open, and toggle the manual override while a comment is half written. The page should update without losing the draft. Check that returning to "auto" really hands control back to the device.
3. Break the storage
If you save the user's choice, test what happens when the stored value is empty, corrupted, or not saved at all. In private browsing, where storage may be blocked, the board should fall back to the device preference and carry on rather than throw an error or stick on the wrong theme.
4. Check the edges
| Area | What to look for |
|---|---|
| Emails | Notification emails render in dark email clients without invisible text or logos |
| Images | Screenshots, avatars and logos with white backgrounds don't glare |
| Forms | Input borders, placeholders and error messages meet contrast |
| Status badges | Text or icon present, not only color |
| Print and export | Printing a roadmap doesn't produce a black page |
| Embeds | Widget inside both a light and a dark host page |
5. Test the widget in the host's real environment
Theme bugs in widgets rarely show up on your own demo page. Load the widget inside the actual app in light, dark and auto, on at least one iPhone, one Android phone and the main desktop browsers your customers use. Confirm the widget matches the host after the host's own toggle changes, not just on page load.
Collecting feedback about the dark theme itself
Once a dark theme ships, people will tell you what is wrong with it. The mistake is letting those reports scatter across support email, chat and social posts, where each looks like a one-off.
Send them to the board. Create a category or tag for appearance and theme, and ask reporters to say which device, browser and theme setting they used. Merge duplicates so votes pile up on one idea. Then you can tell the difference between one person who dislikes a shade of gray and fifty who cannot see the vote button.
A few habits help:
- Ask for a screenshot. Contrast problems are obvious in an image and nearly impossible to describe.
- Respond with a status. "Under review" or "planned" tells people their report was seen. Moving it to "shipped" closes the loop.
- Separate preference from defect. "I'd like a darker background" is a vote-worthy idea. "I can't read the timestamps" is a bug to fix now.
- Check accessibility reports first. Anything that blocks a user from reading or operating the board outranks taste.
If you also run short in-app prompts, pair them with the public board so quick reactions turn into tracked ideas. We cover that approach in feedback inside your app.
Where Petĩra fits
Petĩra is a hosted public feedback board: people post ideas, vote and comment, and you move each idea through under review, planned, in progress and shipped, with a public roadmap, an embeddable widget, moderation tools and email notifications. You can use custom CSS and your own domain to match your brand, connect Slack, Discord or GitHub, and export everything as JSON or CSV whenever you want. If you are moving from another tool, import from Canny, Fider or a CSV file.
Every plan includes unlimited users, ideas and votes at a flat rate. The Free plan costs €0 per month, Pro is €19 per month (or €190 per year), and Team is €49 per month (or €490 per year). See the details on the pricing page.
If you want a board you can theme to match your product, start with Petĩra and put your dark-mode palette into custom CSS from day one.
FAQ
Should a feedback widget follow the device theme or the app's theme?
Both, in that order of priority. If the host app has its own theme switch, pass that setting to the widget so the two always match. If the app has no switch, or the setting is "auto", let the widget follow the visitor's device preference.
Is dark mode better for accessibility?
Not automatically. Some readers find it more comfortable, while others find light text on a dark background harder to read, so the answer depends on the person. What matters is that both themes meet contrast requirements, which is why you offer a choice and test both.
What contrast ratio should a dark mode board meet?
WCAG AA asks for 4.5:1 for normal text and 3:1 for large text, and 3:1 for essential interface components such as button and input boundaries. Check muted text like timestamps and vote counts first, since they are the usual failures.
Do I need JavaScript to support dark mode?
Not for the basics. A stylesheet can respond to the device setting using the prefers-color-scheme media feature. You need JavaScript only for a manual toggle, for remembering the choice, or for syncing the widget with a host app's theme setting.
How do I handle complaints about the dark theme?
Collect them on the board with a theme tag, ask for a screenshot and the device and browser used, and merge duplicates. Fix anything that blocks reading or operating the board right away, and let votes decide matters of taste.
Sources
- prefers-color-scheme CSS media feature, MDN
- Dark Mode Rollout Playbook, The GitLab Handbook
- Understanding Success Criterion 1.4.11: Non-text Contrast, W3C
- Understanding Success Criterion 2.4.13: Focus Appearance, W3C
- C40: Creating a two-color focus indicator, W3C
- How to Meet WCAG (Quick Reference), W3C
- CSS accent-color, web.dev
- How to Test Dark Mode in Apps and Websites, BrowserStack