Are Red Error Messages Enough? How to Use Color in Web Forms

Is red enough to make an error message useful in a web form? Red can draw attention to a problem, but changing a field’s border to red does not explain which value is wrong or how to correct it. White text on some bright reds can also be difficult to read. What matters is a clear connection between the field, the reason for the error, and the next correction. This article uses a hypothetical municipal sports center’s court-booking form to show how error colors, field labels, and recovery instructions work together.

Do not rely on red alone: name the field and describe how to fix it

Imagine that someone tries to submit a court booking with no date selected and an email address that does not match the required format. Instead of showing only “Input error,” add “Select a booking date” beside the date control and “Enter an email address in the format name@example.com” beside the email field. The location of each error and the required correction should remain understandable even when the visitor cannot distinguish the outline colors.

WCAG 2.2 (Web Content Accessibility Guidelines) requires that color not be the only way to convey information. Its Level A error-identification requirement says that when an input error is automatically detected, the affected item and the problem must be identified in text. Level AA also requires known correction suggestions when an automatically detected input error can be corrected safely with a known suggestion. Red is a common design choice, not a required color. Choose an error style that remains distinguishable from the form’s ordinary hints, warnings, and success messages.

If multiple entries need correction, a short error summary above the form can list their names and provide a way to reach them. Each affected control should still have a nearby explanation. Combine a clear error heading, a visible outline, readable text, and a symbol where useful rather than expecting a change of hue to do the whole job.

Example error color palette for a municipal court-booking form

Consider a hypothetical form where visitors choose a date and time slot and enter a contact email address. HEX is hexadecimal notation for specifying colors on the web. Compare each default or error color with the actual surface directly next to it, using the contrast ratio—the relative luminance difference between two colors.

• Page background and headings: Use off-white ■#F7F8F5 with charcoal ■#29363D for the general instructions. Text contrast is approximately 11.66:1. Deep blue ■#285767 headings against the same background have about 7.44:1 contrast. Avoid making all ordinary explanatory text red simply because a form contains errors.
• Form card: On a white ■#FFFFFF card, charcoal ■#29363D field labels provide about 12.43:1 contrast. White ■#FFFFFF differs from the surrounding off-white page ■#F7F8F5 by only about 1.07:1. Use headings and spacing to help visitors identify the form area.
• Normal input fields: Give white ■#FFFFFF fields gray-blue ■#72828B borders. The border contrasts by about 3.98:1 against white and 3.73:1 against the surrounding off-white ■#F7F8F5. Keep visible text labels even before someone begins typing, rather than using disappearing placeholders as the only identification.
• Missing booking date: When validation identifies the missing date, change the affected field outline to deep reddish brown ■#973F39. It contrasts by approximately 6.81:1 with the white ■#FFFFFF field. Show “Select a booking date” in the same reddish brown ■#973F39 on white ■#FFFFFF for about 6.81:1. The outline reinforces the error; it does not replace the message.
• Email in the wrong format: Place a correction explanation below the email input on a pale rose ■#FBEDE9 surface. Deep reddish brown ■#973F39 text reading “Enter an address in the format name@example.com” contrasts by about 5.96:1 with that pale surface. Include both what needs correcting and an example of the format, and do not erase the visitor’s other entered data unnecessarily.
• Error summary above the form: The pale rose ■#FBEDE9 panel differs from the off-white page ■#F7F8F5 by only about 1.07:1, so provide a deep reddish brown ■#973F39 outline. The border contrasts by about 5.96:1 with the rose ■#FBEDE9. Include a heading such as “Check two fields,” with underlined links to the affected fields. Deep blue ■#24516D link text contrasts by about 7.44:1 against pale rose ■#FBEDE9.
• When using bright red: White ■#FFFFFF text on bright red ■#EF6260 has only about 3.19:1 contrast, below the 4.5:1 requirement for ordinary text. A color being called red does not guarantee that its lettering will be readable. Test the specific foreground and background together.
• An alternative to red: If a purple treatment is more distinct from the site’s other messages, try pale lavender ■#F1ECF7 with deep purple ■#684A87 for both error text and an outline. Both have about 6.20:1 contrast against the lavender background. Purple is not inherently an error color either: keep a clear “Input error” heading and specific correction instructions.
• Field after correction: Once the corrected value has actually passed validation, remove the old error state and restore the ordinary gray-blue ■#72828B outline. Its contrast with white ■#FFFFFF is about 3.98:1. Do not communicate a successful correction through border color alone; the displayed state must match the real input value.
• Keyboard focus: For a field reached with the Tab key, show a distinct deep blue ■#24516D focus outline. It contrasts by about 8.49:1 against white ■#FFFFFF. A field can be both invalid and focused, so keyboard focus must remain identifiable independently of its error indication.
• “Review booking details” button: Use a deep teal ■#245E73 button with white ■#FFFFFF lettering, giving approximately 7.18:1 text contrast. The button surface also contrasts by about 6.74:1 with the off-white page ■#F7F8F5. If submission reveals invalid input, guide the user back to those entries; passing local validation alone does not mean a booking has been confirmed.

Ordinary inputs keep a consistent, understated outline, while affected fields receive a meaningful error message and additional visual treatment. The same principle applies whether the chosen error color is red, purple, or another sufficiently readable option.

Test correction, assistive-technology feedback, and resubmission

Once validation has identified an error, HTML (HyperText Markup Language) supports aria-invalid="true" to communicate the invalid state to assistive technology. ARIA (Accessible Rich Internet Applications) attributes such as aria-describedby can connect the input with an element containing the visible error explanation. Do not mark every untouched required field invalid before the visitor has attempted to complete the form; coordinate the state with the validation process.

When the error summary appears, test whether keyboard and screen-reader users can discover it and reach the fields they need to correct. Preserve other entered values where possible, and update or remove error messages when new validation results become available. A network or server failure also needs a different explanation from an email address that fails format validation.

Under WCAG 2.2 Level AA, normal-sized text generally needs at least 4.5:1 contrast against its background and large text at least 3:1. Essential non-text visual indicators needed to identify controls or states generally need at least 3:1 against adjacent colors. Review the form at narrow screen widths as well. HueRoll can compare a selected color with white or black, but it cannot directly compare arbitrary pairs of custom colors or automatically assess WCAG AA or AAA compliance. The custom-pair ratios in this article were calculated separately.