Give every state a second visible signal
WCAG 2.2 Success Criterion 1.4.1 says color must not be the only visual means used to convey information, indicate an action, prompt a response, or distinguish an element. For a form, that means an error cannot be expressed only by turning a border red. Add a concise message, an icon whose meaning is also available as text, or another persistent visual treatment. The same rule applies to success, warning, selection, required status, and changed values.
- Pair an invalid color with specific text such as “Enter a valid email address,” not a generic red outline.
- Pair a success color with a confirmation message that names the action or field that succeeded.
- Pair a warning color with a label or icon and explain whether the user may continue safely.
Separate labels, instructions, and validation messages
A persistent label identifies what a control collects; an instruction explains the expected format; a validation message explains what must change. Do not collapse these roles into placeholder text or a colored asterisk. WCAG requires labels or instructions when content needs user input, and error identification requires detected errors to be described in text. Keep the message adjacent to its control, connect it programmatically, and retain the entered value whenever correction is possible.
- Use a visible label that remains present after the user types, rather than relying on placeholder text.
- State constraints before submission, for example the required date format or minimum password length.
- After validation, identify the affected field and describe the correction without exposing sensitive input.
Test text and component boundaries separately
Text contrast and non-text contrast are different checks. Under WCAG 2.2, ordinary text generally needs a contrast ratio of at least 4.5:1, while qualifying large text needs at least 3:1. Visual information needed to identify user interface components and their states generally needs at least 3:1 against adjacent colors. Test message text against its background, then test the input boundary, selected indicator, error mark, and focus indicator according to the information each one communicates.
- Measure helper and error text independently; a strong border does not compensate for low-contrast words.
- Measure a required input boundary against the neighboring surface when that boundary identifies the control.
- Check icons, checkmarks, and state marks against the colors directly beside them, not an unrelated page color.
Make focus visible in every form state
Keyboard focus is not the same as hover, selection, or validation. A focused invalid field must show both facts at once: which control receives keyboard input and why its current value is invalid. Preserve a dedicated focus indicator instead of replacing it with the error border. Test the indicator on default, error, warning, success, and disabled-adjacent surfaces. Avoid layout shifts when borders change thickness; an outline or reserved border space can keep nearby content stable.
- Use a focus treatment with sufficient area and contrast under the WCAG focus appearance requirements you target.
- Keep the focus cue visible when an error border, filled background, or selected state is also present.
- Test keyboard order and visibility at browser zoom, high contrast settings, and narrow responsive layouts.
Treat disabled controls as a behavior decision
Disabled controls are exempt from several WCAG contrast requirements, but low contrast alone is a poor way to explain why an action is unavailable. A disabled submit button can conceal missing requirements and may be difficult to discover. When practical, leave the action available and explain validation after activation; when disabling is necessary, keep the label legible, prevent interaction correctly, and place a clear explanation near the control or prerequisite. Never use color alone to distinguish disabled from enabled.
- Use the native disabled state only when the control truly cannot be operated in the current context.
- Explain the prerequisite, such as accepting terms or completing a required field, before the unavailable action.
- Do not imitate disabled behavior only with gray styling; ensure keyboard, pointer, and accessibility semantics agree.
Review the complete validation journey
A palette review is incomplete without interaction. Test an untouched form, keyboard focus, valid input, invalid input, submission, server-side rejection, correction, and success. Include a summary when a long form contains several errors, but keep field-level messages as well. Move focus deliberately only when it helps users understand the result. Confirm that live announcements are concise and do not repeat on every keystroke. The final evidence should document colors, contrast pairs, text, icons, and programmatic associations together.
- Verify every state with keyboard navigation, zoom, a screen reader, and at least one forced-colors or high-contrast mode.
- Record exact foreground and background pairs so later token changes can be retested rather than guessed.
- Recheck asynchronous and server errors, because they often bypass the styling and semantics used by client validation.
Primary sources
The factual claims in this article are checked against these published specifications.