网页表单可用性：在不牺牲信任的前提下降低摩擦

少问为先，并解释所需信息

从用户的直接任务出发，只请求完成该任务所需的数据。新闻订阅可能只需要邮箱地址；发货则需要收货地址。二者通常不需要出生日期、职位或捆绑的营销同意。将额外问题延后，除非其对首要结果是必要的。

在表单处说明谁会接收数据及目的，并提供易访问的完整隐私声明链接。受 UK GDPR 约束的组织具有透明义务，包括用途与保留等与上下文相关的信息。这不是普遍的法律建议：在目标市场上请让相关评审人员批准采集与声明文案。

让标签和原生控件完成工作

每个字段、复选框、单选组、选择框和按钮都需要一个描述其用途的名称。使用与控件关联的可见标签，通常通过 label 元素，其 for 值与 input 的 id 匹配。这会扩大可激活区域，并让辅助技术识别正确的控件。将标签靠近输入放置。

提示文本不是字段名称。不要把它当做唯一说明，因为输入后会消失。如果视觉上下文使标签看似多余，仍需在代码中保留可访问名称并进行测试。W3C 指出 title 文本作为主标签替代方案更不可靠。

先为纠正而校验，然后在服务器上强制规则

使用原生约束以实现稳定的检查：正确的 input type、required、length、range 和合适的 pattern。在成为错误之前给出有用的格式示例。客户端校验有助于恢复，但不是安全边界。请求可以绕开它们，因此服务器必须在处理数据前验证相关语法和业务规则。

当提交失败时，保留已接受的值。在表单前放置错误摘要，识别每个字段、解释问题与修正，并提供到该字段的链接。在字段旁重复简洁的信息。将其与控件关联，在适当时指示无效状态，并可预测地将焦点移到第一个错误或摘要。明确确认成功。

仅在反馈稳定且有用时（例如用户名可用性）才在输入过程中验证。那些在中途必然会失败的格式检查通常更适合在离开字段时或提交时进行。用屏幕阅读器测试动态消息；实时更新能提供帮助，但持续打断会产生摩擦。

支持浏览器自动填充和移动端输入

添加具体的 autocomplete 令牌来描述数据：given-name、family-name、email、tel、shipping street-address、billing postal-code、username 和 new-password 都是常见示例。令牌帮助浏览器和密码管理器区分相似字段。自动填充是辅助，不是承诺；行为因浏览器而异，可能依赖于可用的表单、name 或 id，以及提交控件。

使用能提供合适移动键盘并支持基本浏览器校验的 input type。不要阻止密码字段的粘贴或阻碍密码管理器。现代浏览器在登录表单上即便将 autocomplete 设为 off 也可能仍然提供凭据填写，因此要在目标用户使用的浏览器中测试真实路径。

确保可用键盘完成整条路径

用户必须能够在不使用指针的情况下完成表单。键盘操作也支持语音输入和其他产生按键的辅助技术。从表单前到表单后使用 Tab：顺序应符合任务，焦点必须可见，任何控件、对话框、日期选择器、错误链接或帮助面板都不得陷阱焦点不放。

原生控件提供了大部分所需行为。自定义下拉、自定义日期掩码、地址检索、CAPTCHA 替代方案和模态需要刻意的键盘行为、焦点管理和可访问名称。如果自定义组件无法达到可用的原生替代方案，就应简化。对窄屏和高缩放进行测试。

在发布改进时设置护栏并准备回滚

在更改重要表单之前，记录已确认提交的基线、按字段类别的错误、技术故障和完成时间。不要仅为了改进指标而收集原始值或重放敏感数据。将汇总信号与可访问性及键盘检查配对，因为单一比率通常无法解释人们遇到困难的原因。

尽可能一次发布一个实质变化，例如标签措辞、移除可选字段或改进恢复流程。在测试前定义护栏：支付授权错误、支持联系方式或可访问性回归都可能是相关指标。在安全账户和支付测试环境中测试生产配置。支付脚本、数据处理和合规需要合格的安全、支付与法律评审；本文并不证明合规性。

SIU 通过发布预检使这一过程更安全：确认依赖项、客户端行为、服务器响应、确认流程和回滚。这是主动补救措施，不替代团队的实时状态或故障监控流程。