forms

详细介绍

构建让用户能够轻松完成、不会感到困惑、焦虑或中途放弃的表单。目标不是收集所有可能的字段，而是移除用户达成目标路上的一切不必要障碍。

请参阅表单验证模式，了解验证时机、错误位置、多字段依赖、异步验证和恢复设计。请参阅实时验证 UX，了解失焦与实时验证的时机、“早奖励、晚惩罚”的行为，以及便于复制粘贴的验证方式。请参阅错误恢复，了解验证或提交失败后的处理方式。决定是否禁用提交按钮，或保持按钮可用并说明错误原因时，请参阅禁用按钮 UX。请参阅组件解剖，了解按钮、输入框、复选框、单选按钮、切换开关、下拉菜单和文本区域的组件结构指南。

强制准备

用户通过 /forms 启动此工作流。此技能启用后，加载 $frontend-design — 其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议 — 如果尚无设计上下文，必须先加载 $setup。此外，还需了解：用户想要达成什么目标、哪些字段确实必填，以及当前流程中哪些因素会导致用户放弃。

评估表单需求

了解表单的用途和使用情境：

用户目标：完成表单后，用户能得到什么？收益越明确，完成率越高。
字段必要性：每增加一个字段，完成率都会下降。逐一审视每个字段：现在是否必须收集，还是可以之后再收集？
使用情境：用户是否正赶时间、容易分心、使用手机，或处于压力情境中？压力情境下应使用更简单的表单。
失败点：用户目前会在哪些地方退出？表单过长、标签不清晰和意外触发的验证都是常见原因。

表单结构

字段顺序

先询问简单的问题，以建立填写势头
在视觉上将相关字段分组（姓名字段放在一起，地址字段放在一起）
将可选字段放在末尾，或明确标注为可选
只有在账单地址和收货地址确实不同时才将其分开

标签设计

在输入框上方使用清晰、便于浏览的标签（不要将标签放在输入框内充当占位文本）
相比标题式大小写，句首字母大写的形式更易阅读
描述要具体：“卡号”，而不是“付款信息”
辅助文本应说明格式要求，而不是重复标签

输入设计

输入框宽度应与预期内容相匹配（邮政编码输入框不应占满整行）
使用适当的输入类型（type="email"、type="tel"、type="date"），以优化移动设备上的键盘
在用户输入时显示格式提示（信用卡号空格、电话号码分组）
便于自动填充：使用标准的 name 和 autocomplete 属性

多步骤表单

在以下情况下，将较长的表单拆分为多个步骤：

字段超过 6-8 个
表单涵盖不同主题（账户信息、付款、确认）
用户需要在最终提交前进行检查

步骤设计：

显示进度（“第 2 步，共 4 步”），让用户知道还剩多少内容
允许返回之前的步骤
用户离开后再返回时，保留已输入的数据
继续下一步前验证当前步骤，但不要阻止用户向后导航

验证策略

时机

对已明确填写完成的字段（电子邮件、电话、要求特定格式的字段）在失焦时验证
只有在能提供即时帮助时，才在输入过程中验证（密码强度、字符数）
其他内容在提交时验证，尤其是跨字段依赖
切勿验证尚未填写过的字段，这会引发焦虑

错误设计

将错误消息直接放在字段下方
说明哪里出错以及如何修复
使用 aria-invalid 和 aria-describedby 关联屏幕阅读器
验证失败时保留所有用户输入
提交失败后将焦点移到第一个错误处

成功状态

使用勾号或绿色边框，低调地确认字段有效
用户再次编辑字段时，移除成功指示
不要为每个有效字段都提示成功；这会造成干扰

移动端表单 UX

确保触控目标至少为 44×44px
使用合适的输入类型以优化键盘
将表单拆分为多个步骤或使用渐进式展示，以尽量减少滚动
数字字段显示数字键盘，电子邮件字段显示电子邮件键盘
短列表不要使用下拉菜单；改用单选按钮或分段控件

无障碍

使用 for/id 将每个输入框与标签关联
使用 fieldset 和 legend 对字段分组
使用 role="alert" 或 aria-live="polite" 播报表单级错误
确保错误消息以编程方式与字段关联
测试通过键盘浏览整个表单
不要仅依赖颜色来指示错误

反模式

字段过多：每增加一个字段，完成率都会降低
用占位符充当标签：用户输入后占位符就会消失，不利于记忆和无障碍访问
加载时验证：初始状态下的字段显示错误，会让用户觉得受到指责
错误提示含糊：只说“输入无效”而不加说明，会让用户不知所措
出错时清空字段：丢失已输入的数据会让人非常沮丧
禁用提交按钮却不给出指引：灰色按钮没有显示错误，会让用户无路可走
多步骤表单没有进度指示器：用户不知道还剩多少内容
验证时机不一致：有些在失焦时验证，有些在提交时验证，却没有明确的逻辑
忽略移动端键盘：电话号码使用 type="text" 会迫使用户切换键盘
不支持保存后继续填写：无法中途保存的长表单会让用户因中断而受挫