A patient portal's date-of-birth text field signals an error only by turning its border red; what should the design-system spec require instead?
answer
- colour is a reinforcement only
- the error said in words
- right beside the field
- what is wrong, how to fix
- keep the typed value
basics
~20 sAn error message in text, right beside the field, saying what is wrong and how to fix it, with an icon or other non-colour cue, tied to the field so it is read on focus, and the typed value kept.
solid answer
~50 sA red border alone fails two WCAG 2.2 level A criteria: **1.4.1 Use of Color**, because colour is the only signal, and **3.3.1 Error Identification**, because the error is not described in text. People with colour-vision deficiency may not see it, nobody learns *why* the date was rejected, and a screen reader says nothing. The spec should require an error message in a fixed slot directly beside the field, usually below it where the helper text sits, starting with an icon and written as a fix: 'Enter a date of birth in the past, for example 14 03 1962'. When the fix is known, **3.3.3 Error Suggestion** (AA) expects the suggestion. The message is tied programmatically to the field so it is read on focus, the typed value stays in the box, and the red border stays as reinforcement. It appears once the person leaves the field or submits, and clears as soon as the value is fixed.
go deeper
Remember the two level A criteria a colour-only error fails, 1.4.1 Use of Color and 3.3.1 Error Identification, and that the fix is visible text beside the field.
Explain the full anatomy: message slot, non-colour cue, programmatic tie to the field, preserved value, and how the error shares space with the helper text.
Diagnose why a shipped field's errors go unheard or unseen, and weigh layout-shift and helper-replacement trade-offs across a whole library, not one form.
Treat error wording and placement as a system-wide contract with content design, so every team's fields fail the same way and support volume drops measurably.
## What is wrong with a red border alone A **text field error state** is the combination of visual and textual changes that tells a person the value they entered cannot be accepted. Turning the border red is the cheapest possible version, and it fails in several ways at once. - **Colour is the only signal.** WCAG 2.2 success criterion **1.4.1 Use of Color** (level A) says colour must not be the only visual means of conveying information. Someone with red-green colour-vision deficiency may see no change at all. - **There is no description.** **3.3.1 Error Identification** (level A) requires that when an input error is detected automatically, the item in error is identified and the error is described to the user in text. A border describes nothing. - **There is no reason.** Even a person who sees the red cannot tell whether the date is in the wrong order, in the future, or simply unreadable. - **Assistive technology hears nothing.** A screen reader announces the field's name and value; a colour change on its outline is not part of either. ## The anatomy of an inline error | Element | Rule | Why | |---|---|---| | **Message text** | Says what is wrong and how to fix it | Satisfies 3.3.1; 3.3.3 Error Suggestion (AA) expects a known fix to be offered | | **Icon or prefix** | A shape such as an alert mark, or a word like 'Error' | Gives a non-colour cue alongside the red | | **Colour** | Red text and border, as reinforcement | Speeds recognition for people who can see it | | **Programmatic tie** | The message is exposed as the field's description | A screen reader reads it when the field gets focus | | **Preserved value** | The typed input stays in the box | The person corrects rather than retypes | The error colour itself is a palette decision owned elsewhere; what this component spec owns is that colour never works alone. ## Where it goes 1. **Directly beside the field**, usually below it, in the same slot every field uses. The eye learns one place to look. 2. **Near the helper text.** Either the error replaces the helper in its slot or it appears just above it; if it replaces the helper, the message must restate anything the helper said that the person now needs. 3. **Not in a hover or focus bubble.** A message that exists only while a pointer rests on the field is invisible on touch screens and easy to miss everywhere. 4. **Decide on layout shift.** Reserving empty space for the error slot keeps the page still but wastes room on every valid field; letting the slot expand pushes content down. Many systems accept the shift for a short message; either choice is defensible if it is consistent. A page-level error summary linked to each inline error is a whole-form pattern and belongs to the form spec; the inline message is still required beside each field. ## When it appears and disappears The spec states the behaviour; the event wiring belongs to the forms code. The widely used rule is **late to complain, quick to forgive**: - Do not show an error while the person is still typing their first attempt; '1' is not yet a wrong date of birth. - Show it when they leave the field or submit. - Remove it on the change that makes the value valid, so they are not scolded after fixing it. ## Writing the message - Name the fix, not the fault: 'Enter a date in the past' beats 'Invalid date'. - Use the label's words so the message and field clearly belong together. - Avoid blame and codes: no 'You entered it wrong', no 'Error 422'. - Keep it to one line where possible, because it sits in a narrow slot. For the date-of-birth field, a good pair is the helper 'For example, 14 03 1962' and the error 'Date of birth must be in the past. For example, 14 03 1962.' ## Across platforms Web and native mobile platforms each have their own way to attach an error to a field and mark it invalid. The spec should name the requirement, visible text plus a non-colour cue, tied to the field and announced on focus, and let each platform choose its mechanism.
- If a sighted user can clearly see the red border, why is the icon still worth adding?Because colour perception varies more than teams expect, and screens vary too: glare, low-quality displays and high-contrast display settings can wash a red border out. An icon or the word 'Error' gives a shape-based cue that survives all of those, which is what 1.4.1 Use of Color is asking for.
- When can an error message withhold the suggestion for fixing it?WCAG 2.2 3.3.3 Error Suggestion makes an exception when the suggestion would jeopardize the security or purpose of the content. A sign-in field should not say which part of a credential was wrong, and a quiz should not reveal the right answer. Ordinary data entry like a date of birth has no such reason.
saying these in an interview costs you the question
- A red border is enough because everyone recognises red as an error.
- Errors belong in a tooltip so they do not disturb the layout.
- 'Invalid input' is a perfectly good error message.
- Clearing the field after an error helps the person start again cleanly.
- Showing an error on the first keystroke gives the fastest feedback, so it is best.