请 Agent 修复表单：标签、键盘操作与有用的错误提示

为表单修复任务明确三个具体结果：用户能识别每个字段、用键盘完成任务，并知道出错后如何恢复。提供表单状态与所需检查，而不是不描述交互，只让 Agent“把它做得无障碍”。

下面的虚构工作坊申请表提供了一个完整的小型标记案例。它关注字段命名、提交与错误恢复，而不是全面的视觉重设计。

从用户需要完成的表单开始

任务是用姓名、电子邮箱和可选备注申请工作坊。在最初的示例中，用户输入后就看不到字段名称，Send 方框不是原生按钮，错误消息也没有提供恢复指引。

<!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>

这是一份有意不完整的交互设计。请求应指出问题与需要保留的内容：保留三个字段及已输入值，让提交控件可用，并用针对具体字段的指引替换笼统错误。

给 Agent 一个目标错误状态

以下是同一虚构表单在提交无效数据后的原创标记提案。错误状态是编写出来的样例，不是服务器请求、浏览器测试或辅助技术测试的证据。

<!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>

/workshop-requests 动作是示意性的应用接口。你的应用仍需要自己的校验与提交处理器。用错误样例审阅拟议标记，再到真实应用中检查完整交互。

把每项修复与其目的对应起来

W3C 的标签教程说明了显式关联标签与控件的方法；其表单通知指南讨论了清楚易懂的整体反馈与字段反馈。上表将这些思路用于本案例，不是合规结论。

错误属性与消息必须反映实际状态。字段修正并被接受后，应用应移除过时错误状态。提交成功也需要准确的确认，而不是把错误标题留在屏幕上。

复制修复请求

根据给定的修改前标记和目标错误状态样例，修复工作坊申请表。

保留 Name、Email 和可选 Note 字段、它们提交时使用的名称，
以及校验失败时已经输入的值。

用明确可见的标签替换仅靠占位文字标识字段的方式。
用原生提交按钮替换视觉上的 Send 方框。
把提示与字段错误关联到对应控件。
提供能理解的返回错误标题和带链接摘要。

不要添加新 UI 框架，也不要改变请求中的业务字段。
解释初始、无效、已修正和成功状态的区别。
返回标记改动，以及键盘操作/错误恢复检查记录。
把预期行为与实际执行的检查分开。

使用实际结果留空的键盘走查表

走查前记录浏览器、操作系统、输入设置和确切页面状态。以下是拟进行的检查，不是本指南的测试结果。

另外，使用实际支持的辅助技术组合检查输出：控件名称、必填状态、提示、错误，以及修正后的变化。记录观察，不要假定标记审阅就能证明每一次播报或焦点转换。

完成修复应得到可用的表单流程与可追溯的检查记录。修改前后标记为 Agent 划定改动范围；走查表则让你能实际检查结果，而不把一般性的无障碍请求扩展为没有边界的重设计。