招聘方给你一个在线申请页面，请你在不动鼠标的情况下提交表单。第一次 Tab 后看不见焦点。打开附件说明弹层，按 Escape 没有退出，继续按 Tab 又跳到背景页面。自动扫描可能发现一些语义和对比度问题。实际操作还要观察焦点去哪、用户怎样结束，以及能否回到刚才的进度。WCAG 2.2 对键盘操作、焦点可见等提出了要求，Playwright 也建议结合自动化、人工评估及用户测试。 WCAG 2.2 · Playwright 无障碍测试
从一个真实用户目标开始测
模拟页面包含个人资料、上传附件、打开说明和提交申请。测试前先记浏览器、窗口宽度和是否已登录。刷新后用 Tab 从顶部往下，记录能否跳过重复的导航、焦点是否按可理解的顺序移动。到每个输入框时，看标签能否让人知道该填什么。用 Enter 或 Space 激活该控件预期支持的操作。这个过程中可观察键盘单独使用时是否能够完成任务，而不只是控件的形状。
如果焦点到了一个看不见的链接，可以用开发工具查当前元素，再回到页面说明用户看到什么。该元素可能位于已隐藏的菜单，或被固定页头、滚动容器遮住。测试报告可以用屏幕截图和当前焦点的元素名称说明，避免只写“Tab 顺序不对”。对于有自定义控件的项目，先核对它应有的键盘行为。不要为了一致而强迫所有组件使用同一种按键。 MDN 键盘可访问性说明
用三条路径检查弹层
| 路径 | 应看到的行为 |
|---|---|
| 从按钮用键盘打开 | 焦点进入弹层中合适的位置，标题和操作可理解 |
| 在弹层内向前和反向导航 | 能到达应该能操作的控件，操作不会无故跳入被遮挡页面 |
| 用约定的退出方式关闭 | 弹层关闭，焦点回到触发位置或合理的后续位置 |
这里需要区分模态弹层内维持焦点和无法离开的键盘陷阱。设计好的模态弹层可以限制背景交互，只要用户有明确可用的键盘退出或完成方式。如果用户进入后只在两个不可操作元素间循环，或者“关闭”只响应鼠标，这就影响任务完成。面试时说明两者差别，能让工程同事准确知道要修什么。
再试一种实际边界：触发按钮在弹层关闭后因页面更新而移除。此时焦点不可能回到已经不存在的按钮，可以移到同一流程的下一个合适控件。测试里写清这个预期，再检查返回后用户是否知道自己在哪里。条件变化不一定意味着原测试失败，先确认产品流程预期。
给工程师一份可以复现的问题记录
一条缺陷报告可以这样组织：使用指定浏览器在 375 像素视窗打开申请表，依次按 Tab 至“附件说明”，用 Enter 打开，再按 Tab 两次。预期焦点依次落在弹层里的关闭和帮助链接，实际第三次跳到背景页导航，页面视觉上仍有遮罩。附一张焦点状态截图和出现问题的构建版本。这样工程师能在同一场景排查，也知道它为什么会妨碍提交。
设优先级时问哪个任务被阻断。如果候选人完全无法提交，影响会比某个次要提示的焦点样式不一致更直接。两类问题都可以记录，依据页面主流程、受影响用户与替代路径排序。面试官追问“你凭什么说是严重问题”时，说出用户走到哪一步被挡住，以及他是否有可行的下一步。严重程度要由证据支撑。
分清适合自动化和适合人工观察的检查
可以用浏览器测试明确操作步骤与结果，例如触发键盘打开后断言对话框可见，关闭后断言焦点回到对应触发器。自动扫描适合补常见规则，例如控件没有可访问名称。人工观察可继续看长页面滚动时焦点有没有被盖住，以及错误提示是否能让人理解。工具的结果适合互相补充，也需要结合团队对真实用户体验的验收。 Playwright 自动扫描与人工测试建议
用未填必填项的表单再测一次。按提交后，用户应能知道哪一项有问题，并能回到需要改的输入。如果提示只通过颜色出现，屏幕阅读器或看不清颜色的用户可能难以发现。再看文件上传失败的恢复。能否保留其他字段，焦点落在什么地方，用户是否能重新选择文件。一次正常流程只覆盖成功状态，至少还要跑一个会让用户改动或重试的路径。
回归时重现一条以前失败的路径
修复后先跑原始步骤。确认焦点进入弹层，能退出，关闭后回到合理位置。随后试 Shift+Tab、缩放或较窄屏幕，以及表单报错后的焦点。记录哪些环境做过检查，保留一条短录像或可重跑的测试。若你只能验证键盘，不要把这一轮写成“所有辅助技术已兼容”。下一步可以用目标浏览器和辅助技术补测主要路径。
作品集里可以附一张“修复前后对照”。写清你发现的问题、提交给谁、采用的改动和复测结果。面试时让对方改变一个条件，例如表单嵌入另一个页面、按钮在弹层关闭后禁用。你可以指出要补哪个行为，而不是只拿一张扫描报告结束。初级前端和 QA 候选人都可以用这样的案例说明自己会观察页面真实用法。
在十五分钟里完成一次试做
五分钟梳理任务与关键按钮，五分钟只用键盘跑一条失败路径，五分钟写报告并设计回归。让同学按你的报告复现。如果他无法找到“下一次 Tab”从哪里开始，就把初始位置补全。如果他知道步骤却说不出影响，就加上“用户此时还无法提交”的说明。面试中这类修正非常直观，能看出你不仅发现异常，也知道怎样让修复交接下去。
把焦点问题放进复测用例的顺序
有时修复将焦点移动到第一个可点按钮，但该按钮是“删除附件”之类的高影响操作。面试可以提出，初始焦点应根据任务选择更合适的位置，例如说明标题或关闭控制。然后验证用户按 Enter 不会意外删除任何内容。再从关闭按钮逆向 Tab，确认预期循环范围，再从头打开一次，看上一次焦点和错误状态有没有残留。用相同页面在不同时刻验证，可以捕获只在第二次打开时发生的问题。
测试报告还应记清楚哪些操作会触发跳转。比如用户上传失败后点重试，系统可能重新渲染整个附件区。旧元素被替换时，焦点应落在能继续操作的位置。若系统有通知提示，核对用户能否知道上传尚未完成，尤其不要在刚选择文件时把它当作成功。围绕结果而非组件属性写用例，修复后的实现更容易替换，只要使用者仍能完成同一任务。
面试时也可以询问支持范围。团队可能要求至少在 Chrome 和 Safari 跑核心路径，并计划用屏幕阅读器验证一部分流程。把已复测的环境、版本和结果写成简短表格，有助于后续同事复查。尚未验证的设备保留状态，避免把一次本地通过直接扩成所有环境通过。
常见问题（FAQ）
自动扫描通过就代表页面符合要求吗？
自动扫描能覆盖一部分问题，完成路径、焦点变化和使用体验还需要手动或专门测试。
焦点看不到和键盘被困一样吗？
焦点不可见指用户难以判断当前控件。键盘被困指进入后无法通过键盘离开相应组件。两者复现方法不同。
该把每个问题都设为阻断吗？
按用户能否完成任务、是否有替代路径和受影响范围分级，并记录复现证据。
- Web Content Accessibility Guidelines 2.2· W3C
- Keyboard accessible· MDN
- Accessibility testing· Playwright
选一个表单、对话框或菜单，练习记录键盘路径和回归检查，说明哪些问题影响用户完成任务。