Front-End-Checklist 无障碍实战：用 WCAG 2.2 SC 3.3.7 消除多步流程中的重复输入

Front-End-Checklist 无障碍实战：用 WCAG 2.2 SC 3.3.7 消除多步流程中的重复输入

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist

本文基于 Front-End-Checklist 仓库中 redundant-entry 规则文档 展开：多步流程（结账、注册、引导、支持工单）不应要求用户记忆并重新键入本流程中已经提供过的信息。读完本文，你将掌握 WCAG 2.2 SC 3.3.7（Redundant Entry）的判定标准、自动填充与"同账单地址"等复用模式的落地写法、以及自动化 + 手动验证的完整审计方法。

规则是什么：同一个流程中的信息应当被复用

Redundant Entry（冗余输入）指：信息在同一多步流程的前一步已经被收集过，后续步骤却要求用户再次键入。规则的核心诉求只有一句：如果系统已经知道某个值，就应该把它再次呈现出来，而不是把下一步当作一张空白表单。

该规则在仓库中对应两条内容：

• SKILL.md：面向 AI Agent 的速查入口，包含 Quick Reference、Check / Fix / Explain / Code Review 四段式工作流；
• references/rule.md：完整实现细节、代码示例与验证方法，即本文主体。

在 规则库 中，该规则的元数据为priority: high、difficulty: intermediate、estimatedTime: 20，归类为 accessibility / forms 子类，并标注其权威标准来源为 WCAG 2.2 SC 3.3.7。

Why It Matters：为什么重复输入是真实的可用性负担

重复输入是"没有增值的劳动"。在复杂流程中，这种额外劳动会被放大：

• 用户必须记住之前某个屏幕输入的内容；
• 语音、开关（switch）和纯键盘用户会在重复文本输入上花费更长时间；
• 重复字段制造更多拼写错误和值不一致的机会（例如账单地址与收货地址的邮编抄错）；
• 当流程显得"官僚化"而非"辅助性"时，用户更容易中途放弃。

认知、运动或语音输入受限的用户最先受影响，但所有人都能从更少的重复字段中受益——这一点在 SKILL.md 中同样被强调。

Code Example：从"坏示例"到三种正确模式

反模式：让用户确认已输入过的邮箱

<!-- Bad: step 1 collected the same email address already --> <label for="confirm-email">Confirm your email</label> <input id="confirm-email" name="confirmEmail" type="email">

问题在于：如果第一步已经收集过邮箱，第二步再让用户"确认邮箱"就等于强制重新输入。

模式一：预填充 + autocomplete 语义

<!-- Better: show or prefill the previously entered value --> <label for="contact-email">Contact email</label> <input id="contact-email" name="email" type="email" autocomplete="email" value="[e-mail]">

这里同时做了两件事：

• 用value把上一步的值预填充回来；
• 用autocomplete="email"声明字段语义，让浏览器原生自动填充（autofill）也能正确识别该字段。

autocomplete的价值在仓库的 input-types 规则 中有详细展开：语义化type+autocomplete组合可以让回访用户的表单完成速度提升 40%。常用取值包括name、given-name、family-name、email、tel、street-address、address-level2（城市）、postal-code、country-name、cc-number、current-password/new-password等。复用既有数据时，正确的 autocomplete 元数据是"让浏览器与系统都能理解该值"的前提。

模式二：React 中的"Same as billing address"切换

function ShippingStep({ billingAddress, shippingAddress, useBillingAddress, onToggle, }: { billingAddress: Address shippingAddress: Address useBillingAddress: boolean onToggle: (value: boolean) => void }) { const effectiveAddress = useBillingAddress ? billingAddress : shippingAddress return ( <fieldset> <legend>Shipping address</legend> <label> <input checked={useBillingAddress} name="sameAsBilling" type="checkbox" onChange={(event) => onToggle(event.target.checked)} /> Same as billing address </label> <input defaultValue={effectiveAddress.street} name="street" type="text" /> <input defaultValue={effectiveAddress.city} name="city" type="text" /> <input defaultValue={effectiveAddress.postalCode} name="postalCode" type="text" /> </fieldset> ) }

要点解读：

• 勾选Same as billing address后，effectiveAddress指向已输入的billingAddress，三个字段通过defaultValue被预填充；
• 未勾选时，用户只需填写与账单不同的部分，其余字段保留可编辑状态；
• 这是"让先前的值可被选择"（selection）而不是"重新输入"的标准实现——用户在两种地址完全一致时零键入即可完成本步。

模式三：把确认页当成"确认页"

<!-- Better: review previously entered data instead of retyping it --> <section aria-labelledby="review-contact"> <h2 id="review-contact">Review contact details</h2> <p>Email: [e-mail]</p> <p>Phone: [phone]</p> <a href="/checkout/contact">Edit contact details</a> </section>

确认/总结步骤应当展示数据供核对与编辑，而不是要求重新输入一遍。需要修改时提供明确的"Edit"入口（如上例跳回/checkout/contact），并保持已填充字段的值不变。注意aria-labelledby将<section>与标题#review-contact关联，保证读屏用户能准确理解区块语义。

Best Practices：三条最佳实践

1. 在同一任务内复用值

如果用户在当前流程中已经输入过某数据，二选一：

• 自动填充新字段（auto-populate）；
• 让先前值可被选择（make the prior value available for selection）。

常见模式包括：

• "Same as billing address"（同账单地址）；
• 在确认步骤展示之前输入的联络邮箱；
• 从评审文本中选择之前输入过的公司 ID，而不是再次询问。

2. 把确认页当确认页，而不是空表单

确认步骤通常应展示数据供检查和编辑，而非要求完整重新输入。若需修改，提供编辑动作或保持字段已填充。仓库的 SKILL.md 建议：检查结账、注册、引导、支持工单等流程时，逐字段对比各步骤，标记那些"应被自动填充或可从先前输入中选择"却被再次索取的字段。

3. 把真正例外限制在真正的例外

WCAG 的例外比许多团队以为的要窄得多。重新输入只有在以下情况才有效：

• 对活动本身至关重要（essential to the activity itself）；
• 出于安全需要（required for security）；
• 先前提供的信息已不再有效（no longer valid）。

这意味着：密码确认可能是可接受的，但重新输入收货城市、邮箱地址或支持工单号通常不可接受。

Thresholds：判定通过 / 失败的标准

• Pass（通过）：如果先前输入的非豁免数据在同一流程的后续步骤中被预填充或可选；
• Fail（失败）：如果用户必须在同一流程中手动重新输入相同的联系信息、地址或资料信息。

Standards：与 WCAG 2.2 的对应关系

• 本规则映射到WCAG 2.2 成功标准 3.3.7 Redundant Entry（在 规则库元数据 中，该标准被标注为role: standard、authority: primary的来源）；
• 允许的例外很窄：必要信息、安全要求的重输、或信息已失效。

在仓库的规则体系中，该规则还与以下相邻规则关联（见 redundant-entry.mdx 的relatedRules）：

• form-validation：两者都作用于长表单或多步表单，重复纠错工作会显著增加任务摩擦；
• session-timeout-recovery：跨步骤保留信息与跨超时保留信息是同一用户旅程的相邻环节；
• accessible-authentication：认证与恢复流程常因要求重输已提供数据而同时违反两条规则；
• input-types：良好的字段语义与自动填充元数据让复用先前数据更容易、更可靠。

Exceptions：窄而明确的例外清单

• 重设新密码可以是合法的安全例外——用户必须确认一个不显示的秘密（非明文展示的密文）；
• 如果先前的值已过期或被有意作废，再次询问是正确的；
• 不要通过"比必要时间更久地存储敏感数据"来规避本规则——在流程内复用先前数据的同时，不要制造新的隐私泄露（例如不因复用而延长密码、卡号等敏感信息的留存时长）。

Verification：如何审计一个多步流程

自动化检查（Automated Checks）

• 映射流程中的每一步，列出每个必填字段；
• 标记所有重复出现的值——凡出现一次以上、却未从前一步被预填充或可选择引用的字段，即为违规点。

手动检查（Manual Checks）

• 以真实用户身份完整走完流程（从开始到结束）；
• 通过：重复信息已经存在，或无需重新键入即可选择；
• 失败：用户必须在同一流程中手动重新输入相同的非豁免值。

面向 AI Agent 的落地：从 Check 到 Code Review

仓库将本规则包装成可被 Agent 直接执行的技能（SKILL.md），其四段式工作流对人工审查同样适用：

1. Check：审查该多步流程，找出在同一流程中被索取一次以上的信息，标记应自动填充或可从前值中选择的字段；
2. Fix：在同一流程内复用先前输入的信息——自动填充重复字段、在合适位置加 "same as" 切换、跨步骤保留数据，让用户无需重输；
3. Explain：向团队解释 WCAG 2.2 Redundant Entry、什么算"同一流程"、何时安全/有效性例外允许重输；
4. Code Review：审查多步表单、结账、引导、支持与账户流程，精确标记"先前输入的信息被再次要求、却没有自动填充或选择机制"的具体步骤。

技能元数据还给出一个关键审计原则（aiContext）：审查覆盖多个屏幕、步骤或模态阶段（modal stages）的流程时，要跟随真实用户旅程、跨步骤比较字段，而不是孤立地审查单个界面——这同样是一条值得人工测试者遵守的准则。

小结

Redundant Entry 是 WCAG 2.2 新增的输入辅助类标准，核心策略是"系统已知道的值，就别让用户再敲一遍"：用value预填充、用autocomplete声明语义、用 "same as" 切换复用地址、用确认页展示而非重输。结合本仓库的 规则文档、Agent 技能 与 规则库元数据，团队可以在设计、开发、测试和 AI 审查四个环节统一口径，把多步流程从"官僚化"改造成"辅助性"。

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist