Accessible form error messages and validation

WCAG calls anything a user enters that a form does not accept an input error: a required answer left blank, or a value in the wrong format or outside the allowed values (W3C's Understanding page for 3.3.1). The error is rarely the problem. The problem is that the person never learns it happened or cannot tell how to fix it. Someone who cannot see a red outline may not notice that anything changed, and "Invalid input" leaves everyone guessing. W3C says flagging errors helps people with reduced sight and cognitive disabilities resolve them.

This guide covers what the criteria ask, how to write, place, connect and announce each message, and how to test it. The examples are invented. It is part of how to make a website accessible; labels and instructions are in accessible forms.

What WCAG requires of error messages

These six success criteria bear most directly on form errors.

Three points from W3C's notes shape the rest of this guide:

• No display method is mandated. Errors can be listed before the form, shown beside each field or presented in an alert or dialog, so long as they are in text. Color or an image may be added to the text but cannot replace it.
• One message can meet two criteria. In W3C's example, a message saying only that the email is not valid meets 3.3.1, while one that also gives the expected email format meets 3.3.1 and 3.3.3.
• The code connection is covered elsewhere. W3C says 3.3.1 does not itself require programmatic information about an error. Criteria such as 4.1.2 Name, Role, Value may. In GotAlt's reading, a message beside a field is also a relationship shown by position, the territory of 1.3.1 Info and Relationships.

Write each message to name the field, the problem and the fix

W3C's forms tutorial on user notification asks for messages that are concise, easy to understand and give simple instructions for resolving the problem. Four habits follow from W3C's guidance:

• Name the field the way its label does. "Expiry date", not "field 3". The same words in the label, the message and the error summary let a person match them.
• Say what is wrong in words, not in a code and not as "Invalid".
• Say how to fix it. W3C's technique G85 asks the message to give an example of correct entry, describe it or show similar valid values. Where the correction is known, offer it, as G177 does. W3C's Understanding page for 3.3.3 gives an example: for a month-name field that received "12", list the valid names or ask "Do you mean 'December'?"
• Keep what the person typed. G85's test checks that previously entered data is shown again, except in a security-related field such as a password.

Show errors where people will find them

The W3C tutorial separates overall feedback, given once after a submission, from in-line feedback at each field. Use both.

1. Put the result in the page title and the h1, in the pattern "3 errors: Billing address". The tutorial notes that screen reader users receive a title as soon as the page loads, and technique G83 adds that a user may otherwise assume the form was accepted and move on.
2. List the errors in a summary before the form, under a distinctive heading. Each item should refer to the field's label, describe the error, say how to correct it and link to the field. W3C's technique G139 treats such a mechanism for jumping to errors as advisory, not required.
3. Repeat each message beside its field, in the same words.
4. Move focus on purpose. The tutorial sets focus on the first field with an error. G139's third example sets it on a link that starts the list of errors. Either gives a keyboard user a starting point. Leaving focus on the Submit button does not, in our reading.

Connect each message to its field in code

A message that only sits near a field in the layout is not tied to it for someone moving through the form with a screen reader. The W3C tutorial and technique ARIA21 tie them together with aria-describedby on the field. ARIA21 adds aria-invalid="true" to mark the field as failing validation:

<label for="expiry">Expiry date</label>
<input id="expiry" name="expiry" type="text"
       aria-invalid="true"
       aria-describedby="expiry-hint expiry-error">
<p id="expiry-hint">Use the format MM/YYYY.</p>
<p id="expiry-error"><strong>Error:</strong> the expiry date is not in the
  format MM/YYYY. Enter it like 03/2027.</p>

• Keep the label as the field's name and the error as its description. G83 warns that some screen readers may not announce a change to a label.
• Set aria-invalid only after validation fails. ARIA21 says not to set it before validation has run, and MDN says not to set it on empty required fields until the person has tried to submit.
• Start the message with "Error:" so it does not depend on color, as W3C's own examples do.
• Know the alternative. MDN also documents aria-errormessage, but the W3C material above uses aria-describedby, so we show that. See ARIA basics for when to use ARIA at all.

Announce errors that appear without a page load

When a script adds an error without reloading the page, nothing moves focus, so assistive technology needs a cue. Criterion 4.1.3 covers this. An error shown in a dialog that takes focus is a change of context, which W3C says is outside 4.1.3 (see accessible modals). For the rest, W3C's technique ARIA19 uses role="alert" or a live region, and makes three points:

• The container must already be in the page when it loads, then be filled with the message. W3C says otherwise most screen readers will not speak it.
• Adding aria-atomic="true" is needed for VoiceOver on iOS to read the errors again after more than one invalid submission.
• role="alert" equals aria-live="assertive", which interrupts. W3C's 4.1.3 page lists assertive announcements for content that is not important and time-sensitive as a failure, and warns that too many live messages can make an application too chatty for screen reader users.

Choose when to validate, and what to do about browser messages

W3C's tutorial shows three moments to check: after submit, when focus leaves a field and while the person types. In our reading, submit is the baseline, because a server can do it without client-side scripting. Checking when the person leaves a field suits formatted data such as dates, because checking while they type would show an error most of the time, W3C says. Checking while typing needs scripting and suits fewer forms, such as username availability. MDN advises against setting aria-invalid on an empty required field before the person has tried to submit, and in our reading the same goes for a visible message.

HTML's built-in validation (required, type="email") blocks submission and shows a browser message. W3C says that meets 3.3.1 in common browser and screen reader combinations, since focus returns to the first invalid field and the message is announced. It lists drawbacks: the message may not be permanent or scroll with the page, may not enlarge when the user zooms in, is often too generic for 3.3.3, and shows only the first error. MDN's validation guide describes the novalidate attribute, which turns off the browser's own messages so you can show yours in the page. One approach, in our reading, is to keep the HTML rules, add novalidate and write the messages and summary described above.

Do not rely on color, icons or placeholders

• Color. W3C's Understanding 1.4.1 lists an error shown in red among its examples of information conveyed by color, and says an outline that is green for valid and red for invalid needs an additional indicator. The words "Error:" plus the message are that indicator. Our guide to color and links covers the same criterion.
• Contrast. Normal-size error text needs 4.5:1 against its background (1.4.3), so check the pairing on a tinted error box. Our reading is that an icon or border carrying the error should also reach 3:1 (1.4.11), though that criterion names no error state. See the color contrast guide.
• Icons. An icon beside the word "Error:" repeats it, so give it an empty alt or hide it (decorative images).
• Placeholders. A placeholder disappears when someone types and is not a label (our placeholder guide). Keep format hints in visible text beside the label.

Check it yourself

An error state exists only after someone submits a bad entry, so test each form template in that state.

1. Submit the empty form, then put one wrong value in each kind of field and submit again. Does every error appear as text, name its field and say how to fix it? Is what you typed still there?
2. Use only the keyboard. After submitting, where is focus? Can you follow each summary link to its field? Our keyboard accessibility test has the rest of the routine.
3. Take color away. Screenshot the form with its errors showing and load it in our color blindness simulator, which has a lightness-only view. Can you still find every error, and does each one say in text what is wrong? Then check the error text and its background in the contrast checker.
4. Zoom to 200%. W3C notes that default browser messages may not enlarge.
5. Listen with a screen reader. Tab to an invalid field: do you hear its label, that it is invalid and the message? After a scripted submit, is the summary announced once? See how screen readers read a page.

The free accessibility bookmarklet reads the page as it is when you click it, so submit the form first and run it with the errors showing. It flags form fields with no label and fields labeled only by their placeholder, which matters because the February 2026 WebAIM Million found missing form input labels on 51% of home pages. None of its checks covers error text, aria-invalid or aria-describedby, so it cannot tell you whether a message is helpful or connected to its field. Scan my site for free reads the HTML your server sends and does not fill in or submit forms, so error messages that appear only after a bad entry are outside what it reads. What we check lists every rule.

Passing these checks does not show that a form meets WCAG or any law. For the wider routine, see how to test website accessibility.