# 1. jest-axe 在 React/Vue 组件单测的无障碍断言工程实践 A jest-axe 在组件单测中断言无 axe 违规，覆盖静态规则，但验证不了键盘/焦点等动态行为 ✓ 正确答案 B jest-axe 能验证全部读屏体验 C jest-axe 只能用于 Vue D jest-axe 会替换所有其他测试
# 2. Chrome DevTools 的 Accessibility 面板（Accessibility Tree） A 它展示辅助技术实际读取的可访问性树，可查看名称/角色/状态/ARIA 计算，排查语义问题 ✓ 正确答案 B 它只显示视觉样式 C 它只能查看性能 D 它无法查看 ARIA 计算
# 3. WAVE 浏览器扩展在视觉化无障碍问题的工程应用 A 它只能用于 Chrome 移动端 B 它能自动修复所有无障碍问题 C 它在页面上用图标可视化标出错误/警告/通过项，适合人工审查，但无法验证键盘与读屏行为 ✓ 正确答案 D 它验证全部读屏体验
# 4. NVDA + Firefox 与 VoiceOver + Safari 在屏幕阅读器测试的工程取舍 A 只需测一套即可 B 所有读屏浏览器组合行为完全一致 C NVDA+Firefox（Windows）与 VoiceOver+Safari（Apple）是覆盖主流用户的两套常用组合 ✓ 正确答案 D 读屏测试与浏览器无关
# 5. axe-core / lighthouse --accessibility 在 CI 集成 a11y 自动检测的工程价值 A lighthouse 的 accessibility 不与 axe 相关 B 两者功能完全相同 C CI 无法自动检测 a11y D axe-core 提供细粒度规则断言，lighthouse 提供可衡量得分门槛，二者都可集成 CI 自动检测回归 ✓ 正确答案
# 6. Pa11y CI 在 CI/CD 的持续无障碍审计 A 它与 axe 完全无关 B 它只跑一次 C 它无法配置阈值 D 它是基于 axe 规则的 CI 工具，支持页面列表、阈值、忽略列表与基线对比，持续防回归 ✓ 正确答案
# 7. Lighthouse Accessibility 审计 A 它基于 axe 规则输出得分与审计项，可量化追踪，但覆盖不了键盘/读屏等动态行为 ✓ 正确答案 B 它能验证全部读屏体验 C 它只测性能 D 它无法纳入 CI
# 8. Playwright expect toHaveAccessibleName/toHaveRole 的工程价值 A 它们断言元素的可访问名称与角色，能验证 aria-label 计算与 role 语义是否正确 ✓ 正确答案 B 它们只断言 CSS 样式 C 它们无法验证 ARIA D 它们只能用于读屏
# 9. Pa11y/axe-core 与 Storybook a11y addon 在组件级 a11y 测试的工程价值 A 组件测试无法测 a11y B jest-axe 自动化断言 + Storybook a11y addon 可视化审查，从组件源头保证无障碍 ✓ 正确答案 C 只需页面级测试 D Storybook addon 与 axe 无关
# 10. 键盘测试与屏幕阅读器测试的方法 A 键盘测试只有人工 B 两者都完全自动化 C 读屏测试不需要人工 D 键盘测试验证 Tab 顺序/焦点/触发，读屏测试验证名称/状态/播报，读屏主要靠人工 ✓ 正确答案
# 11. 可访问性测试在 CI/CD 的集成 A CI 无法集成 a11y B 只需一个工具即可 C 分层集成：jest-axe 组件级、axe 页面级、Pa11y/Lighthouse 全站级，并管理基线/阈值/忽略列表 ✓ 正确答案 D 单测即可覆盖全部
# 12. Lighthouse Accessibility Score 的工程优化与边界 A 100 分即完全无障碍 B 它是自动化规则通过率的代理，高分不等于真正无障碍，仍需人工与读屏测试 ✓ 正确答案 C 它覆盖键盘与焦点 D 得分无法优化
# 13. Automated Accessibility Testing Tools（a11y 工具） A axe-core 是核心规则引擎，Pa11y/Lighthouse/jest-axe 等工具在其上构建或封装，互补使用 ✓ 正确答案 B 工具之间互不兼容 C 只需一个工具即可 D 自动化工具能覆盖全部无障碍
# 14. axe-core 的 run 在 Puppeteer/Playwright 集成的工程实践 A Playwright 无法集成 axe B axe.run 无法在浏览器中运行 C 通过 axe.run() 在页面上下文扫描并返回违规，可用 @axe-core/playwright 封装，断言无违规 ✓ 正确答案 D 扫描结果无法定位违规元素
# 15. Lighthouse CI 在 PR 检查的无障碍回归测试的现代应用 A 它无法对比基线 B 它只跑一次 C 它在 PR 中跑审计、对比基线、设得分门槛，新增问题即失败，防无障碍回归 ✓ 正确答案 D 它不能集成 GitHub Actions
# 16. 无障碍测试的 prefers-reduced-motion 与 prefers-color-scheme 的边界 A 它们与无障碍无关 B 需模拟这些媒体查询（如 Playwright emulateMedia）验证深色模式对比度与动画降级是否生效 ✓ 正确答案 C 只需测试默认样式 D 无法模拟媒体查询
# 17. WCAG 2.2 新增准则（Focus Appearance、Dragging Movements） A 焦点环无需对比度 B 两者都只涉及配色 C 拖拽必须是唯一交互方式 D Focus Appearance 要求焦点环有足够对比度/尺寸，Dragging Movements 要求拖拽提供单指针替代操作 ✓ 正确答案
# 18. Playwright 的无障碍快照（accessibility snapshot） A 它无法验证 role B 它返回 DOM 文本 C 它返回可访问性树快照（role/name/状态），可对比做语义回归，验证的是语义树而非 DOM 文本 ✓ 正确答案 D 它只用于视觉测试
# 19. ARIA 验证工具（ARIA Validator）在团队规范的现代实践 A 它无法检测拼写错误 B 它只能人工判断 C 它能校验 ARIA 属性合法性/适用性，可纳入 lint 与 CI，配合团队规范从源头减少无效 ARIA ✓ 正确答案 D 它与 axe 无关
# 20. Screen Reader 模拟器（ChromeVox Extension） A 它只用于读屏学习 B 它是唯一准确的读屏 C 它是 Chrome 内置读屏，可快速测试读屏行为，但播报与 NVDA/VoiceOver 有差异，不能完全替代真实读屏 ✓ 正确答案 D 它无法朗读内容
# 21. 无障碍测试在 RTL（右到左）语言与国际化的工程实践 A 国际化无需 a11y 测试 B RTL 只需改文字 C dir 属性影响读屏 D 用 lang/dir 声明语言与方向，用逻辑属性适配 RTL，并测试本地化文本的可访问名称与布局 ✓ 正确答案
# 22. axe-core 自定义规则（Rule/Check）的开发流程与 axe.configure 注册 A 自定义规则无需注册 B 只能使用内置规则 C 通过定义 Rule（含 Check）并用 axe.configure 注册，可扩展 axe 覆盖项目特有规范 ✓ 正确答案 D Check 与 Rule 无关
# 23. 键盘 Tab 顺序的自动化断言方法（tab-order 测试、焦点序列快照对比） A 只需人工检查 B Tab 顺序无法自动化 C 通过模拟 Tab 收集 activeElement 得焦点序列，与期望或快照对比，防 Tab 顺序回归 ✓ 正确答案 D 焦点序列无法记录
# 24. 屏幕阅读器自动化测试（guidepup、VoiceOver Control）的工程实践与局限 A 它能完全替代人工读屏测试 B guidepup 可驱动真实读屏（NVDA/VoiceOver）断言输出，但环境重、慢、脆弱，辅助而非替代人工 ✓ 正确答案 C 它无需真实读屏 D 它只测视觉
# 25. axe-core 与 Lighthouse Accessibility 在自动化无障碍审计的覆盖差异与工程价值 A 两者完全一致 B axe 提供细粒度可配置断言，Lighthouse 提供整体得分与审计报告，二者互补而非替代 ✓ 正确答案 C Lighthouse 覆盖规则多于 axe D 二者互不相容
# 26. axe-core 在 CI（@axe-core/playwright/cypress-axe）的工程集成与现代协作 A CI 无法集成 axe B 只能独立使用 axe C E2E 中无法扫描 D @axe-core/playwright 的 AxeBuilder 与 cypress-axe 在 E2E 中扫描并断言，配合分层测试形成回归防护 ✓ 正确答案
# 27. WAVE（WebAIM）浏览器插件在手动无障碍审计的工程价值 A 它验证全部读屏体验 B 它能自动修复问题 C 它可视化标出问题与结构视图，适合手动审计与团队沟通，但无法验证键盘/读屏行为 ✓ 正确答案 D 它只能用于 CI
# 28. NVDA、JAWS、VoiceOver、TalkBack 在屏幕阅读器测试的兼容性边界 A 只需测一套 B 所有读屏行为一致 C 读屏与 OS/浏览器组合存在差异，常以 NVDA+Firefox/Chrome 与 VoiceOver+Safari 为主流矩阵测试 ✓ 正确答案 D 读屏与浏览器无关
# 29. axe-core 的规则集（wcag2a、wcag2aa、wcag21a、best-practice）在项目的取舍 A 所有规则集固定不可配置 B 规则按 wcag2a/2aa/21aa/best-practice 等分组，取舍依据合规目标与误报容忍度 ✓ 正确答案 C best-practice 是 WCAG 强制项 D 只需 wcag2a
# 30. Pa11y CI 在仪表板与统计无障碍问题的工程价值 A 它无法对比基线 B 它只输出 0/1 C 它支持多页扫描、问题统计、基线对比与趋势追踪，让无障碍问题可量化可治理 ✓ 正确答案 D 它不能追踪趋势
# 31. 无障碍的 Lighthouse 评分与真实用户（盲人）测试 A 真实用户测试可被自动化替代 B Lighthouse 高分即完全无障碍 C Lighthouse 是自动化兜底与门槛，真实用户（盲人）测试能发现自动化盲区，两者结合 ✓ 正确答案 D 只需 Lighthouse
# 32. Screen Reader 在 JavaScript 重 SPA 中的可访问性（Live Region、Focus Management） A 用 live region 播报动态变化 + 焦点管理（路由/弹窗后迁移与归还）+ aria-busy 表加载，是 SPA 无障碍关键 ✓ 正确答案 B SPA 无需处理读屏 C 焦点无需管理 D 动态内容无需播报
# 33. axe-core 的 impact 等级（minor/moderate/serious/critical）在严重性排序的取舍 A 所有问题 impact 相同 B impact 是绝对权威 C impact 按 minor/moderate/serious/critical 分级，用于排序修复与 CI 阈值，但只是启发式辅助 ✓ 正确答案 D 只需关注 minor
# 34. Storybook 8/9 的 @storybook/addon-a11y（基于 axe-core）的视觉化无障碍测试的现代工程价值 A 它无法高亮违规 B 它只能测性能 C 它基于 axe 在 story 中可视化显示违规并高亮元素，适合组件库把无障碍固化到组件源头 ✓ 正确答案 D 它与 axe 无关
# 35. VoiceOver（macOS/iOS）的 rotor 导航与现代 Web 应用的兼容边界 A rotor 依赖语义化结构（heading/landmark/表格等），缺乏语义的 Web 会使 rotor 导航失效 ✓ 正确答案 B rotor 不依赖语义 C rotor 只用于 iOS App D 无结构也能良好导航
# 36. prefers-reduced-motion/prefers-reduced-transparency/prefers-contrast/forced-colors 在自动化测试的工程协作 A 这些媒体查询无需测试 B 通过 emulateMedia 模拟 reduced-motion/contrast/forced-colors 等，验证各偏好下的降级与适配 ✓ 正确答案 C 无法模拟媒体查询 D 它们只影响性能
# 37. axe-core Linter（VS Code）与 eslint-plugin-jsx-a11y 在开发期无障碍协作的边界 A eslint-plugin-jsx-a11y 与 axe Linter 在编码期拦截静态问题，但无法覆盖运行时行为，需配合运行时测试 ✓ 正确答案 B 它们能验证全部无障碍 C 开发期 lint 足够 D 它们无法静态检查
# 38. NVDA 与 Chrome 在 IE 模式下表单错误 ARIA 描述的朗读兼容性边界 A IE 完全支持 ARIA B IE 对 aria 描述支持有限，需用 aria-describedby 优先并以可见文本兜底，识别朗读缺口 ✓ 正确答案 C IE 模式无需处理 D aria-errormessage 在 IE 支持最好
# 39. 无障碍回归测试的基线建立与豁免（ignore list）治理，避免误报淹没真实问题 A 应一次性清零所有问题 B 建立基线对比"新增问题即失败"，用带理由的 ignore 豁免已知/误报，定期评审避免噪音淹没真问题 ✓ 正确答案 C 豁免无需理由 D 误报也应修复
