How can I make a website work when users override text colors?

Treat the override as a real presentation to test, not as an unusual edge case. Browser color settings can replace colors chosen by the page, and color changes can also remove visual grouping that your design relied on. [S1] Start by changing the browser’s foreground and background colors, then go through the same screens and interactions a visitor would use. [S1]

For each control, ask: Can I tell what it is? Can I read its label? Can I tell whether it is focused, selected, unavailable, or reporting an error? A control may be identified by a visible label or a sufficiently contrasting icon even if its boundary is not visible; focus still needs a sufficiently contrasting indicator. [S3] Don’t assume that the authored colors remain in effect during this review.

Use that form as a checklist of distinct cues. For the submit button, confirm that its label still identifies it even if its colored fill disappears. For each field, check that the field and its label remain distinguishable from nearby content; a layout cue or border can help preserve structure when color changes. [S2] For the error, verify that its text is still legible and that the issue is communicated by words, not just the red color. That last point is a practical review suggestion: the cited guidance does not prescribe how a particular form must phrase errors.

Then move keyboard focus through the form and check each focused control. Focus must remain visibly identifiable with sufficient contrast. [S3] If an error, required state, or selected state is conveyed by a color change, check that state separately rather than assuming the normal control appearance proves it will be clear.

For CSS pages, one documented approach is to specify layout and borders while leaving text and text-background colors unspecified, allowing browser or operating-system settings to provide them. [S2] It is an example to consider, not a required implementation or a guarantee that every design will behave well. W3C also cautions that a technique that leaves colors to users may not suit layouts whose backgrounds carry important structure. [S1]

Check your actual page in the browsers that matter to your audience. Browser behavior varies: for example, pop-ups can become transparent or menus can render differently when colors are overridden. [S2] The cited guidance does not establish identical results across browsers or cover every browser, operating system, widget, or override setting. If a particular menu or pop-up loses its structure, revise that component and retest it in that presentation.

Yes. Use this short pass on each important page, recording the browser and override setting so someone else can repeat the check. For every interactive component, inspect its normal appearance, keyboard focus, and any state that changes what a user should do. Pay particular attention to controls whose identity, grouping, or status currently depends on a colored background. The W3C guidance specifically calls for checking the page with user-selected foreground and background colors in effect. [S1]

If a boundary or state indicator carries visual information needed to identify a component or its state, check its contrast against adjacent colors; WCAG 2.2’s non-text contrast criterion gives a 3:1 minimum for that information, subject to exceptions. [S3] This does not mean every border must be visible: a clear label or sufficiently contrasting icon may identify a control without one. [S3] Record failures as observations, such as “focus indicator disappears on the search button,” then retest after a change. This review is a practical check, not proof that every user-agent presentation will match.