BrettH reported an accessibility issue in the Select-kit dropdown where selected items (e.g., notification levels) lose visibility because text and icons disappear against the selection background. This occurs due to insufficient color contrast, particularly in custom themes using older color palettes. The root cause lies in the select-kit.scss file, where the .is-selected state applies a background color but fails to override foreground colors, relying on defaults that may not contrast with the user’s specific palette.
While bryce could not reproduce the bug in their environment, chapoi and awesomerobot identified that the issue stems from outdated custom color palettes created before the introduction of specific selected and hover color variables. They suggested that the computed fallback values for backgrounds do not account for the text colors defined in older palettes. NateDhaliwal also inquired about testing in safe mode to confirm if the issue is theme-specific.
BrettH confirmed the diagnosis, noting that their palette was set up prior to these updates. They plan to create a new color palette with explicitly defined selected and hover colors to ensure proper contrast. Additionally, BrettH proposed a potential feature request: improving the fallback calculation logic to automatically consider text contrast, thereby preventing similar issues for users with legacy palettes without requiring manual intervention.
When using the topic notification dropdown (Watching/Tracking/Normal/Muted), the currently selected item’s text and icon become invisible due to insufficient contrast between the selection background color and foreground colors.
Steps to reproduce
Open any topic
Click the notification bell button at the bottom of the topic
Observe the currently selected notification level (e.g., “Tracking”)
Expected behavior
The selected item should have clearly visible text and icon with good contrast.
Actual behavior
Text label disappears or becomes very hard to read
Bell icon becomes invisible
Issue is most noticeable in dark themes but can affect any theme depending on color palette
Technical details
In app/assets/stylesheets/common/select-kit/select-kit.scss, the .is-selected state only sets the background color without ensuring foreground contrast:
&.is-selected,
&.is-selected.is-highlighted {
background: var(--d-selected);
// No color override for text or icons
}
The --d-selected CSS variable comes from the theme’s $selected color, but the text (.name, .desc) and icons (.d-icon) retain their default colors which may not contrast well with the selection background.
It looks like your color palette hasn’t been updated in a while maybe, because that’s not the normal selected colour. When did you last update your forum?
Yeah this is likely the case — I’ve seen situations like this where a custom color palette that was created before new colors were added ends up with poor contrast… @BrettH if you create a new color palette and use that, does the issue persist?
Thanks everyone for the suggestions. Let me address the questions:
NateDhaliwal - I haven’t tested in safe mode yet, but based on what chapoi and Kris are describing, I suspect safe mode would resolve it since it would fall back to the default Light palette rather than my custom one.
@chapoi - Good question. Our color palette was created quite a while ago - definitely before the selected and hover colors were added to the base palette. I believe the palette was set up when we first launched the community, and we haven’t updated it since.
@awesomerobot - That makes sense. Looking at the code, I can see that resolved_colors computes fallback values for hover and selected using dark_light_diff if they’re missing from the palette. But the problem is the text colors (.name, .desc, .d-icon) still use their default values, which were designed for the default Light palette’s selection color - not the computed fallback for my darker theme.
I’ll create a new palette and explicitly set the selected and hover colors to values that contrast properly. I suspect that will fix it.
One thought while I’m testing: would it make sense for the fallback calculation to also consider text contrast? That way older palettes would gracefully handle new color additions without manual intervention. Just an idea - I know color systems are tricky to get right, and the current approach probably covers most cases. Happy to file a separate feature request if that’s helpful.
