English version · 区块链学习导航 · 上一篇
区块链学习 · 延伸文章 BCX004
区块链界面并不是给按钮加上标签就实现了无障碍。使用者需要能够进入正确网络和账户，理解动作，完成授权交接，获知有意义的状态，并在恢复时避免误重复操作。每个边界都可能使原本可读的页面无法使用。
本课通过九个给定检查点评价一项虚构端到端任务。有些失败涉及键盘或辅助技术访问，另一些涉及传达状态是否真实。它们共同决定使用者能否在知情控制下完成任务。
练习使用模拟提供方和合成设备记录，没有真实钱包、秘密、交易、凭证颁发、付款或个人数据。我们分析的是给定观察，不声称进行过实时无障碍审计。结果是任务范围内的验收判断，不是WCAG符合性证书。
选择适合你的阅读路线
本篇目录
- 1. 定义使用者要完成的动作
- 2. 阅读九项检查证据
- 3. 分开标准与特定任务要求
- 4. 不用指针也能进入和检查上下文
- 5. 在授权交接中保留有意义的焦点
- 6. 把账户或网络变化视为重要上下文变化
- 7. 准确传达等待、失败与完成
- 8. 区分提交前取消与提交后断开
- 9. 给出任务范围内的验收结论
- 10. 复测前，先规定修复后流程
- 11. 保留可复现测试记录
- 练习与参考答案
- 常见问题
- 来源与延伸阅读
第1至3节定义任务、检查点和审查依据；第4至8节检查导航、交接、上下文变化、状态和恢复；第9至11节提供判定、拟议修复与复测记录。通用基础可参考辅助技术如何恢复访问能力。
1. 定义使用者要完成的动作
模拟应用允许获授权练习办公室，把合成设备记录Record17的复核标记设为Reviewed。预定上下文为网络N1、练习账户Office-A。该操作不声称真实设备已经检查，记录仅为教学样例。
授权前，使用者应能识别N1、Office-A、Record17、确切变更和范围。提供方连接成功不等于允许执行变更；核对摘要不等于签名，签名也不等于已确认应用成功。
被测试流程有六个大阶段：选择上下文、准备变更、核对、处理模拟授权窗口、观察提交、得知最终结果。另有恢复路径处理取消、账户变化与连接中断。
界面应让这些阶段可理解、可操作。没有说明的转圈图标或熟悉账户图标，不能承担全部含义；使用者也不应只能从按钮颜色变化猜出失败。
2. 阅读九项检查证据
每个检查点是独立测试样例。即便前面存在阻碍，后续检查也从题目指定状态开始。这样才能检查整个流程，而不假装键盘使用者能够经过不可访问的第一步。
材料明确提供虚构界面的键盘可达性、焦点和辅助技术观察，也提供相关应用结果。本练习接受这些观察；真实测试应记录实际浏览器、操作系统、辅助技术及其版本。
- C1：只能用指针选择网络，没有键盘等效路径。
- C2：核对页面以可读文本展示完整合成网络、账户、目标和动作，并能无障碍地检查各标识。
- C3：模拟授权模态窗口打开，但焦点留在背后，按给定键盘路径无法到达窗口控件。
- C4：核对后账户从Office-A变成Office-B，旧核对仍标记为当前有效，无需重新核对即可提交。
- C5：使用者在任何签名或提交前取消，应用准确报告没有操作被提交。
- C6：提交后只有彩色转圈图标变化，给定辅助技术输出中没有有意义的等待状态。
- C7：给定回执显示应用执行失败，界面却报告记录颁发成功。
- C8：提交后提供方断开连接，界面将操作称为已取消，并提供没有限定说明的重复动作。
- C9：经验证据确认执行成功并满足指定最终性条件，界面准确呈现结果，同时保留网络和请求上下文。
3. 分开标准与特定任务要求
WCAG 2.2提供无障碍框架，其配套Understanding页面解释键盘操作、有意义焦点顺序和可感知状态消息等要求。这些解释属于信息性指南；规范性成功准则和符合性要求来自推荐标准本身。
本清单还规定特定任务完整性要求：账户改变会使先前核对失效，等待中的操作不能说成完成，断开连接不能说成取消。这些是本虚构流程明确要求，并不表示每项都是措辞相同的独立WCAG准则。
分开以后，判断更准确。审核者可以指出键盘、焦点障碍或虚假执行消息，而不把标准扩张到它没有说过的内容。少量检查通过，也不能证明整站符合标准。
若要解释供应商真实报告，可参考阅读无障碍符合性报告。本课则追踪一个具体区块链交互如何跨越多个边界。
4. 不用指针也能进入和检查上下文
C1未通过指定键盘要求。使用者不能通过给定键盘界面或等效路径选择所需网络。选择器外观再漂亮，也不能解决这种访问障碍。
W3C的键盘说明要求功能可通过键盘接口操作，并对本质上依赖移动轨迹的输入规定特定例外。本样例选择网络不需要徒手轨迹。修复应提供可操作、可发现的路径，而不是只给指针控件增加装饰性标签。
C2通过给定上下文检查要求。使用者能够阅读N1、Office-A、Record17及Reviewed标记，不只依赖颜色或截断标识。它本身不认证真实网络，而是确保界面能表达独立设置证据提供的上下文。
真实长标识可采用简短标签加可访问完整详情。关键是重要差异仍可检查，不必每步都逐字符朗读长串；但简写也不能隐藏区分两个上下文的唯一方式。
5. 在授权交接中保留有意义的焦点
C3未通过模态任务要求。授权窗口虽然看得见，给定键盘使用者却无法到达控件，也不能沿此路径核对或取消。障碍发生在另一个组件，不能成为主应用宣布流程无障碍的理由。
W3C的焦点顺序说明强调保留含义和可操作性。本模拟窗口的拟议修复，是把焦点移到窗口内有意义位置，使模态交互可用，并在关闭后返回合理位置。
这是针对本样例的设计建议，不表示每个真实钱包窗口技术实现相同。浏览器扩展、独立窗口或移动端交接，可能需要不同测试。应记录哪个组件控制各次交接，以及哪个团队负责修复。
不要为缩短导航而删除核对步骤。无障碍设计应保留理解和拒绝动作的机会，也不应把索取恢复短语或私钥当成“无障碍替代方式”。本模拟任务无需公开秘密。
6. 把账户或网络变化视为重要上下文变化
C4未通过规定核对绑定要求。使用者核对的是Office-A，现在活动账户却是Office-B。旧摘要仍显示有效，会让下一动作使用未经核对的上下文。
拟议修复应将旧核对标记为过时，以易懂文字告知账户已改变，并要求重新检查更新后的上下文，再启用授权路径。适当时应保留安全草稿，而不是悄悄提交或突然丢弃全部内容。
EIP-1193定义了链和可用账户改变时的提供方事件，帮助应用获知上下文变化。但收到事件并不是用户同意，也不保证应用已正确更新所有摘要或等待请求。
本样例中，网络改变同样需要谨慎核对。另一个网络上看起来相同的账户文字，不证明相同记录或权限。应用应解释什么变了、用户需要重新核对什么，而不能暗示切换显示网络就擦除了先前提交的操作。
7. 准确传达等待、失败与完成
C6未通过等待状态要求。彩色转圈图标没有向给定辅助技术使用者提供有意义状态，使用者无法判断是在等授权、已提交、执行中还是已完成。
W3C的状态消息说明讨论让辅助技术能够呈现程序化状态信息，而不要求焦点移到消息上。修复可以提供简洁的“已经提交，结果尚未确认”，同时允许继续阅读。
这不意味着每产生一个区块就反复播报。拟议设计应报告有意义状态变化，并让最新状态随时可检查。不断打断可能降低可用性，却不增加决策所需信息。
C7失败原因不同：消息不真实。给定回执确认应用执行失败，界面却说颁发成功。让错误消息更容易被听到，不能解决完整性缺陷。修正文本应说明请求变更失败及其证据上下文，不能暗示交易或账户其他所有方面都已回滚。
C9通过给定结果要求，因为文字与已验证执行成功及指定最终性证据一致，并保留请求和网络上下文。但这只是该检查点通过，不能抹去C6或C7失败。
8. 区分提交前取消与提交后断开
C5通过，因为前提明确：在任何签名或提交之前取消，模拟组件确认没有提交操作。界面准确报告这个范围有限的结果，应把使用者带回可操作位置，并说明保留的草稿状态。
C8失败，因为提供方在提交之后断开。断开阻止或中断当前观察路径，并不证明已提交操作取消，也不证明它不能执行。界面的取消声明没有依据。
本样例中，没有限定说明的重复动作也不安全，因为原结果仍未确定。拟议修复应保留请求身份，报告观察缺口，并在建议其他操作前提供适当状态恢复路径。但不能承诺重连总能取得结果，也不能假设所有网络取消机制相同。
这种区别对所有使用者都重要，包括依赖屏幕阅读器输出的人。如果唯一播报是“已取消”，他们可能合理地认为不会再有外部效果。因此，准确恢复文字属于知情控制的一部分，不是可有可无的技术脚注。
9. 给出任务范围内的验收结论
按给定要求，C2、C5、C9通过；C1、C3、C4、C6、C7、C8失败，即三项通过、六项失败。本清单下，完整流程不能接受，因为关键上下文选择、授权访问和结果解释仍有问题。
不能把三项除以九项变成WCAG符合性百分比。这些检查点是为特定任务选择，不是完整标准清单、统计样本或按严重性加权的评分。一处关键障碍，就可能让整个任务无法完成，即使其他页面表现良好。
发现应保留不同原因：C1需键盘等效路径；C3需修复交接焦点和可操作性；C4需使核对失效并重新协调上下文；C6需有意义且可访问状态；C7需真实结果映射；C8需保留不确定性的恢复方式。
这会给负责人具体修复计划，而不只是“改善无障碍”的模糊要求，也防止换颜色或加标签被误当成应用状态错误的修复。
10. 复测前，先规定修复后流程
拟议修订流程中，使用者通过键盘到达网络选择器，选择合成网络，并检查完整动作上下文。核对状态明确绑定N1、Office-A、Record17和确切变更。
模拟授权组件打开时，有合理焦点位置和可用核对、取消控件；关闭后回到逻辑位置。授权前若账户或网络改变，核对失效，界面先解释新上下文，再让使用者继续。
给定提交之后，状态说明“已经提交，但结果未确认”。失败应描述请求应用动作失败；只有证据同时支持执行成功和最终性，才使用相应成功文字。断开时保留标识和未确定状态，而不是假装取消历史。
这些是拟议验收行为，不是已经实现或测试的修复。复测必须使用实际修订组件和支持的浏览器、辅助技术组合。书面设计证明意图，不证明交互实际可用。
11. 保留可复现测试记录
每项检查应记录起始样例、组件版本、输入方式、步骤、焦点位置、无障碍名称和状态播报、可见状态、底层结果证据，以及观察结论。把预期行为与实际发生分开。
应包含仅键盘操作和相关辅助技术使用，不把自动扫描当成全部评价。在可行时，让有相关访问需求的人参与，并适当保护同意与隐私。本课不提供真实参与者数据，也不诊断任何人。
记录跨组件责任。应用自身正确但模拟钱包交接失败，端到端任务仍失败；反过来，提供方事件正确发出，也不证明应用的无障碍状态或核对绑定正确。
表单提交状态前置文章解释一般保存、提交和恢复清晰性。本课额外任务，是在链与账户变化、授权边界和独立验证执行状态之间，持续保留这种清晰性。
练习与参考答案
- 哪些检查通过？在给定前提下，C2、C5、C9。
- 即使Office-B也有某些权限，C4为什么仍失败？原核对针对Office-A。本样例要求重新核对变更上下文，不能假设使用者已同意。
- 如果C7仍说成功，增加无障碍播报能修复吗？不能，内容相对于给定执行证据仍然虚假。
- C8断开是否证明取消？不能，请求已提交，只是当前中断观察路径下结果未确定。
- 修复后九项全部通过，能认证WCAG 2.2符合性吗？不能，它只证明被测范围内这些任务检查，不涵盖全部适用准则和符合性条件。
写作练习：替换C8的“出错了，请重试”。更好的合成消息是：“请求T1提交后连接中断。这里尚未确认结果。请保留请求标识，在开始另一操作前检查其状态。”这不会声称动作失败，也不会声称重复操作无害。
常见问题
无障碍只涉及屏幕阅读器吗？
不是。键盘、焦点、可理解状态和可感知信息，对不同访问需求与输入方式都可能重要。本清单只抽取特定障碍，不涵盖所有需求。
每次状态改变都要移动焦点吗？
不需要。许多状态消息应在不移动焦点时供辅助技术取得；模态窗口等主动上下文变化有不同交互要求，应测试实际流程。
为使标识可读，界面应该公开秘密吗？
不应该。公开上下文与动作细节，不同于恢复短语或私钥。无障碍不要求泄露秘密，本练习也不含秘密。
接下来学什么？
先读所链接的通用无障碍与表单状态基础，再练习写出包含账户、网络变化和不确定结果的完整任务轨迹，而不是只评价孤立按钮。
来源与延伸阅读
- WCAG 2.2：规范性准则与符合性框架，2026年10月12日核对。
- W3C Understanding页面：键盘、焦点顺序、状态消息，均为信息性解释，2026年10月12日核对。
- EIP-1193：提供方链、账户及连接事件，2026年10月12日核对。事件不是动作授权或执行证明。
- 辅助技术如何恢复访问能力、阅读无障碍符合性报告、表单提交状态原理：通用基础。
无障碍区块链任务，应让使用者理解正在授权什么、跟踪实际发生了什么，并在证据不完整时重新取得控制。