Ask an Agent to Repair a Form: Labels, Keyboard Use and Useful Errors

Give a form-repair task three concrete outcomes: people can identify each field, complete the task with a keyboard and understand how to recover from an error. Supply the form state and the checks you need, rather than asking an agent to “make it accessible” without describing the interaction.

The fictional workshop form below provides a complete small markup case. It focuses on field naming, submission and error recovery rather than a general visual redesign.

Start with a form someone needs to finish

The task is to request a workshop using a name, an email address and an optional note. In the initial example, the field names disappear as people type, the Send box is not a native button and the error message gives no recovery instruction.

<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><title>Workshop request</title></head>
<body>
  <h1>Request a workshop</h1>
  <form action="/workshop-requests" method="post">
    <input name="name" placeholder="Name" value="">
    <input name="email" placeholder="Email" value="sample@">
    <textarea name="note" placeholder="Note">An afternoon session.</textarea>
    <p style="color: red">Something went wrong.</p>
    <div class="send-box">Send</div>
  </form>
</body>
</html>

This is deliberately incomplete interaction design. The request should name what is wrong and what to preserve: retain the three fields and their entered values, make the submission control usable, and replace the generic error with field-specific guidance.

Give the agent a target error state

Here is original proposed markup for the same fictional form after an invalid submission. The error state is authored as a fixture; it is not evidence of a server request, browser test or assistive-technology test.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>2 errors — Workshop request</title>
  <style>
    label, input, textarea { display: block; }
    input, textarea { max-width: 100%; }
    :focus-visible { outline: 3px solid #175cc0; outline-offset: 3px; }
  </style>
</head>
<body>
  <main>
    <h1>2 errors — Request a workshop</h1>
    <section aria-labelledby="errors-title">
      <h2 id="errors-title">Please correct these fields</h2>
      <ul>
        <li><a href="#request-name">Enter your name.</a></li>
        <li><a href="#request-email">Enter a complete email address.</a></li>
      </ul>
    </section>
    <form action="/workshop-requests" method="post">
      <p>Fields marked required must be completed.</p>
      <label for="request-name">Name (required)</label>
      <input id="request-name" name="name" autocomplete="name"
             required value="" aria-invalid="true"
             aria-describedby="name-error">
      <p id="name-error">Enter your name.</p>

      <label for="request-email">Email (required)</label>
      <p id="email-hint">We will use this address to reply to your request.</p>
      <input id="request-email" name="email" type="email"
             autocomplete="email" required value="sample@"
             aria-invalid="true" aria-describedby="email-hint email-error">
      <p id="email-error">Enter a complete email address, such as person@example.org.</p>

      <label for="request-note">Note (optional)</label>
      <textarea id="request-note" name="note">An afternoon session.</textarea>
      <button type="submit">Request workshop</button>
    </form>
  </main>
</body>
</html>

The /workshop-requests action is an illustrative application endpoint. Your application still needs its validation and submission handler. Use the error fixture to review the proposed markup, then check the full interaction in the actual application.

Map each repair to its purpose

Repair	Exact connection in this case	What to inspect
Persistent field labels	Each label's `for` matches its control's `id`	Name, Email and Note remain identifiable after typing
Supporting text	Email references `email-hint`	The explanation belongs to the correct field
Field error	The invalid field references its own error text	People can identify what to correct
Overall feedback	Heading and linked summary identify both errors	The returned page explains what prevented completion
Submission	Native `button type="submit"`	Keyboard activation follows the form's submission path
Retained input	Note and invalid email stay visible	Correcting one field does not require re-entering the whole form

W3C's labeling tutorial explains explicit label/control association. Its form notification guidance covers understandable overall and field-level feedback. The table applies those ideas to this particular case; it is not a compliance verdict.

The error attributes and messages must reflect the actual state. After a field is corrected and accepted, the application should remove its stale error state. A successful submission also needs its own accurate confirmation, rather than leaving the error heading on screen.

Copy the repair request

Repair the workshop request form using the supplied before markup
and target error-state fixture.

Keep the Name, Email and optional Note fields, their submitted names,
and entered values when validation fails.

Replace placeholder-only identification with explicit visible labels.
Replace the visual Send box with a native submission button.
Connect hints and field errors to the relevant controls.
Provide an understandable returned-error heading and linked summary.

Do not add a new UI framework or change the request's business fields.
Explain how initial, invalid, corrected and successful states differ.
Return the markup change and a keyboard/error-recovery check record.
Separate expected behavior from checks actually performed.

Use a keyboard walkthrough with a blank result column

Record browser, operating system, input settings and the exact page state before the walkthrough. These are proposed checks, not results from this guide.

Step	Expected check	Actual observation
Open the error fixture	Page title and heading identify the workshop request and its errors	—
Move with Tab and Shift+Tab	Interactive elements have a visible, usable focus indication and a sensible sequence	—
Activate each summary link	Its corresponding field is reached; record actual focus behavior	—
Edit Name and Email	Labels remain visible and the optional note stays intact	—
Submit corrected data in the application	The intended handler runs and returns an accurate next state	—
Return an error through the application	Appropriate values and messages remain associated with the fields	—

Check assistive-technology output separately with the combinations you actually support: control names, required state, hint, error and changes after correction. Record those observations instead of assuming markup inspection proves every announcement or focus transition.

The finished repair is a usable form flow with a traceable check record. The before/after markup gives the agent a bounded change; the walkthrough gives you a practical way to inspect the result without turning a general accessibility request into an unbounded redesign.