CSS prefers-contrast: strengthen an already readable interface

When to use it

A case review card already has readable text and a visible border. Under a higher-contrast preference, increase the border weight and remove a faint decorative shadow that adds noise. The sample changes only that card; links and focus rings need their own review. Do not make the default contrast poor and expect the media query to rescue users. Some platforms may not expose the preference as expected, so the baseline must stand on its own. Test more contrast, no preference, dark mode, forced colors, and high zoom. A media query cannot tell you whether a particular text/background pair actually passes a measured contrast threshold.

.case-review-card { border: 1px solid #41637c; box-shadow: 0 2px 8px rgb(23 49 72 / 12%); }
@media (prefers-contrast: more) { .case-review-card { border-width: 3px; box-shadow: none; } }

Cost and verification

The extra border has little rendering cost but may reduce inner space in a fixed-width card, so use border-box sizing if dimensions are tight. Review every state of an interactive component rather than only its resting screenshot. Preference matching varies by user environment and does not guarantee the same outcome as forced colors. Keep semantic status labels in text and avoid using contrast changes to indicate a new business state. Verify the computed colors and borders on the actual surfaces, including disabled and selected cards.

Common Mistakes

• Do not let the default presentation fail contrast checks.
• Do not equate prefers-contrast with every forced-color setting.
• Do not use border strength as the only status indicator.

Connected lessons

• CSS Property Decisions
• CSS color and contrast: pair text with its real surface
• CSS dark mode and forced colors: honor distinct user settings
• CSS border, radius, and outline: separate box edges from focus indication