Q413: Implementation Drill Dark Mode Contrast Audit For Action Controls
What Interviewers Want To Evaluate
This drill tests whether you can audit theme changes beyond the background color.
Dark mode often fails in buttons, badges, focus rings, code blocks, and secondary controls.
The interviewer wants to see a systematic contrast audit and a reusable fix.
Short Interview Answer
For dark-mode button issues, I would avoid hard-coded white backgrounds and define semantic button variables for primary background, foreground, border, secondary background, secondary foreground, hover background, and hover foreground. Then every button variant can inherit readable colors in both themes.
Audit Targets
Check:
primary buttons
secondary buttons
compact buttons
theme toggle
copy buttons
reset and clear buttons
read-more pills
status badges
focus rings
disabled states
Secondary buttons are common failure points.
They often keep a white background in dark mode.
Token Strategy
Use variables:
button background
button foreground
button border
secondary background
secondary foreground
hover background
hover foreground
Semantic tokens prevent one-off fixes.
They also make future theme changes easier.
What To Avoid
Avoid:
background white
color white
hard-coded black
hover text that assumes light mode
transparent buttons without border contrast
Hard-coded color names are usually where theme bugs hide.
Manual Verification
Check:
light mode
dark mode
system mode in dark OS setting
hover
focus
disabled
mobile toolbar wrapping
practice page buttons
reader progress buttons
The same button class appears in many routes.
Fix once, verify broadly.
Common Mistakes
- Fixing only one button instance.
- Forgetting hover text color.
- Leaving compact buttons with inherited bad contrast.
- Not checking focus state.
- Testing dark mode only on the homepage.
Final Mental Model
Dark mode button quality is:
semantic tokens
variant coverage
hover and focus states
route-wide verification
no hard-coded white assumptions
Theme polish is a system concern.