How do I connect form instructions and error explanations to a field?

Give the input a visible label, then put its instruction and error explanation in separate elements with their own IDs. Reference the relevant IDs from the input using aria-describedby. The attribute identifies elements that describe an object; the cited guidance illustrates connecting explanatory text by ID. [S1] Guidance also recommends labeling every input and writing errors that explain what went wrong and how to fix it. [S2]

For example, if the form requires a date in a particular format, the instruction could say “Enter the date as MM/DD/YYYY.” If the entry fails that rule, an error could say “Enter the date as MM/DD/YYYY.” Use the form’s actual requirements; these example words don’t establish rules for a real form.

<label for="appointment-date">Appointment date</label>
<p id="date-help">Enter the date as MM/DD/YYYY.</p>
<input id="appointment-date"
       name="appointment-date"
       aria-describedby="date-help date-error"
       aria-invalid="true">
<p id="date-error">Enter the date as MM/DD/YYYY.</p>

This shows an invalid state. The error text and aria-invalid="true" should reflect the field’s actual state, not appear as a permanent warning.

Give each text element its own ID so the field can reference the descriptions that apply. In the example, date-help identifies the instruction and date-error identifies the error; both are listed in aria-describedby. The attribute can identify one or more descriptive elements by ID. [S1]

Keep the messages useful as well as connected. An instruction should say what to enter, and an error should state what went wrong and how to fix it. [S2] For example, “Invalid date” names a problem but gives no correction; a format-specific message gives a next step when that format is the actual requirement.

Check that each referenced ID exists and belongs to the intended field. Include an error ID only when that error text is present and relevant.

Before a problem is found, show the label and instruction without marking the field invalid. When the value fails the form’s rule, show a specific error, include its ID in aria-describedby, and set aria-invalid="true". The cited guidance describes aria-invalid as indicating that a value does not conform to an expected format. [S1]

For a valid state, remove the error text and its ID from aria-describedby, and don’t mark the field invalid. Keep the label and any relevant instruction. These snippets illustrate associations; they do not specify how a particular application validates or clears errors. Use the field’s real rules.

Review each field’s label, instruction, and any current error together. Check that the IDs referenced by the input point to text for that same field. Then ask: does the label make the field’s purpose clear, does the instruction state what is expected, and does the error explain what went wrong and how to fix it? [S2]

Use examples that should pass and fail under the form’s stated rules to review the content and state changes. Confirm the error and invalid state correspond to an actual problem and are no longer present once the value is corrected. This review does not establish complete accessibility or behavior in every environment; the cited guidance supports the described associations and writing advice, not a full validation implementation. [S1] [S2]