Published lesson · 30 minutes

Label forms and explain input errors

Objective: Build a form whose controls have programmatic labels and whose instructions and errors clearly explain what a person needs to do.

The core idea

This lesson introduces label forms and explain input errors. Build a form whose controls have programmatic labels and whose instructions and errors clearly explain what a person needs to do. Begin with one small goal and make sure the result serves a real visitor or collaborator. The examples use fictional community information, so they can be adapted without exposing anyone’s private details.

The key idea is this: A label connects a visible question with its form control. Instructions explain a format before an error occurs. An error should identify the field, describe the problem in plain language and explain how to correct it. Keep that idea separate from visual decoration or tool-specific habits. When you can explain why a choice helps the intended task, it becomes easier to review the result and to choose a different approach when the situation changes.

Put it into practice

Apply it to this situation: A community garden interest form can ask for a name and a way to reply. Keep each label visible. If a phone number is optional, say so. If a date is required, explain the expected format before submission. Start with the smallest useful change. Inspect what changed, describe what you expected to happen and compare the result with the goal. This makes practice possible on a shared device or with limited connectivity.

Watch out for this: Placeholder text disappears as someone types and does not replace a label. A red border alone does not explain an error, and clearing every field after one error makes recovery harder. If something does not work, return to one known-good version and change one detail at a time. Do not include real names, contact details, passwords or access keys in examples, screenshots or shared project history.

Review your work before moving on. Navigate the form with a keyboard and a screen reader. Confirm each control has a name, required status is clear, errors are connected to fields and entered information stays in place after a failed submission. A useful explanation names the audience, the decision and one check. Keep a short record of remaining questions so a facilitator or another learner can help without guessing what happened.

  • Name the task and audience before editing.
  • Make one focused change and inspect it.
  • Record one thing to improve or confirm next.

Worked examples

Label forms and explain input errors: a small example

See how label forms and explain input errors supports a clear, inclusive community web task.

index.html

<label for="reply-email">Email address</label>
<input id="reply-email" name="email" type="email" aria-describedby="email-help">
<p id="email-help">We will use this only to reply about the garden day.</p>

Practice tasks

  1. Explore the example

    Explore the label forms and explain input errors example. Change one small detail for a different fictional community situation, then explain what you expected and how you checked it.

  2. Build a focused result

    Create a small result that demonstrates this objective: Build a form whose controls have programmatic labels and whose instructions and errors clearly explain what a person needs to do. Keep the information fictional and explain one limitation that a future version should address.

  3. Review and explain your decision

    Review your label forms and explain input errors result from another person's point of view. Name one strength, one exact uncertainty and a change that would make the result clearer or safer.

Label forms and explain input errors is easier to learn when you name the goal, make one focused change and check the result with the people who need to use it.

Course overview