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.7Redundant 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 forconfirm-emailConfirm your email/label input idconfirm-email nameconfirmEmail typeemail问题在于如果第一步已经收集过邮箱第二步再让用户确认邮箱就等于强制重新输入。模式一预填充 autocomplete 语义!-- Better: show or prefill the previously entered value -- label forcontact-emailContact email/label input idcontact-email nameemail typeemail autocompleteemail valuesamexample.com这里同时做了两件事用value把上一步的值预填充回来用autocompleteemail声明字段语义让浏览器原生自动填充autofill也能正确识别该字段。autocomplete的价值在仓库的 input-types 规则 中有详细展开语义化typeautocomplete组合可以让回访用户的表单完成速度提升 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 legendShipping address/legend label input checked{useBillingAddress} namesameAsBilling typecheckbox onChange{(event) onToggle(event.target.checked)} / Same as billing address /label input defaultValue{effectiveAddress.street} namestreet typetext / input defaultValue{effectiveAddress.city} namecity typetext / input defaultValue{effectiveAddress.postalCode} namepostalCode typetext / /fieldset ) }要点解读勾选Same as billing address后effectiveAddress指向已输入的billingAddress三个字段通过defaultValue被预填充未勾选时用户只需填写与账单不同的部分其余字段保留可编辑状态这是让先前的值可被选择selection而不是重新输入的标准实现——用户在两种地址完全一致时零键入即可完成本步。模式三把确认页当成确认页!-- Better: review previously entered data instead of retyping it -- section aria-labelledbyreview-contact h2 idreview-contactReview contact details/h2 pEmail: samexample.com/p pPhone: 1 555 0100/p a href/checkout/contactEdit 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 的relatedRulesform-validation两者都作用于长表单或多步表单重复纠错工作会显著增加任务摩擦session-timeout-recovery跨步骤保留信息与跨超时保留信息是同一用户旅程的相邻环节accessible-authentication认证与恢复流程常因要求重输已提供数据而同时违反两条规则input-types良好的字段语义与自动填充元数据让复用先前数据更容易、更可靠。Exceptions窄而明确的例外清单重设新密码可以是合法的安全例外——用户必须确认一个不显示的秘密非明文展示的密文如果先前的值已过期或被有意作废再次询问是正确的不要通过比必要时间更久地存储敏感数据来规避本规则——在流程内复用先前数据的同时不要制造新的隐私泄露例如不因复用而延长密码、卡号等敏感信息的留存时长。Verification如何审计一个多步流程自动化检查Automated Checks映射流程中的每一步列出每个必填字段标记所有重复出现的值——凡出现一次以上、却未从前一步被预填充或可选择引用的字段即为违规点。手动检查Manual Checks以真实用户身份完整走完流程从开始到结束通过重复信息已经存在或无需重新键入即可选择失败用户必须在同一流程中手动重新输入相同的非豁免值。面向 AI Agent 的落地从 Check 到 Code Review仓库将本规则包装成可被 Agent 直接执行的技能SKILL.md其四段式工作流对人工审查同样适用Check审查该多步流程找出在同一流程中被索取一次以上的信息标记应自动填充或可从前值中选择的字段Fix在同一流程内复用先前输入的信息——自动填充重复字段、在合适位置加 same as 切换、跨步骤保留数据让用户无需重输Explain向团队解释 WCAG 2.2 Redundant Entry、什么算同一流程、何时安全/有效性例外允许重输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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考