Write accessible errors for appointment forms
Use different messages for an unreadable date, an unavailable slot and uncertain booking status, and connect errors to their fields.
An error message needs to explain what the person can do next. “Invalid input” barely helps with a date format and misdescribes an appointment that has already been taken. An uncertain booking status needs a different response again.
Three situations and suitable messages
The following appointment service is fictional. It uses a text field for the date and provides a list of existing bookings. The example date is 14 December 2026.
Situation | Example message |
|---|---|
Date format cannot be read | “Enter the date as DD/MM/YYYY, for example 14/12/2026.” |
Selected slot has since been taken | “This slot is no longer available. Choose another time.” |
Connection lost after submission; booking status unknown | “Your booking status is uncertain. Check your appointment list before booking again.” |
The third message does not say the booking failed: that is not yet known. In the example, “Open appointment list” links to existing bookings. If the actual product has no such list, it needs another reliable way to establish the status.
Connect the message to its field
Show the format and example before an error occurs. Support the input methods your audience needs where possible; avoid unnecessarily restrictive formats. This reduced example shows the text field after a format error:
<label for="appointment-date">Date</label>
<p id="appointment-date-hint">DD/MM/YYYY, for example 14/12/2026</p>
<input id="appointment-date" name="appointmentDate" type="text"
value="14/12" aria-invalid="true"
aria-describedby="appointment-date-hint appointment-date-error">
<p id="appointment-date-error">Enter the date as DD/MM/YYYY.</p>The IDs connect the label, hint and error to the same field. Colour can help, but the message must also make sense without a red border. The W3C WAI tutorial explains this association through aria-describedby and understandable correction guidance.
After a valid correction, remove the error text, its reference and the invalid state; the format hint can remain. This markup alone does not establish that the whole form is accessible.
Test the route to correction
When submission produces several errors, a summary with links to the affected fields helps. Decide whether focus should move to the summary or the first invalid field, then test with a keyboard and the intended screen readers. Dynamically updated messages need to be perceivable without unnecessarily interrupting every keystroke.
In the example service, a person should correct an invalid date without re-entering other valid details. Then check that the old error is no longer announced. When a slot is taken, retain the other details while the person chooses another time. When booking status is uncertain, the next step first establishes what happened to the existing booking.
Include an explicit success message showing the confirmed appointment in the test. That is how the person knows the task is complete.
Sources
Read more
All articles
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.