可访问性工程化

• caption、th scope、thead/tbody 的原生表格语义
• ARIA grid 模式与原生 table 的取舍
• 键盘网格导航（方向键移动、编辑、排序）的实现

基础语义：caption 提供表格标题、th scope="col/row" 建立表头与单元格的关联、thead/tbody/tfoot 分组，屏幕阅读器据此朗读行列上下文；复杂表格（可排序、可编辑、冻结列）单靠原生 table 语义不足，需升级为 ARIA grid 模式：容器 role="grid"，行 role="row"、单元格 role="gridcell"（表头 rowheader/columnheader），配合 aria-colindex/aria-rowindex 应对 DOM 与视觉行列不一致。键盘网格导航工程实现：方向键在单元格间移动（记录焦点坐标、Tab 进入/离开网格）、Home/End 跳行首尾、Ctrl+Home 到网格起点，编辑单元格用 Enter/F2 进入、焦点恢复与 aria-required/aria-invalid 播报，排序按钮用 aria-sort 表达状态。关键：grid 模式要求完整键盘契约，实现复杂度高，静态表格优先原生 table。

考察复杂表格的无障碍工程：原生语义覆盖基础、grid 模式提供导航与状态表达，答案需说明升级条件与键盘契约实现。

• AA 与 AAA 的合规门槛差异
• 各成功准则的可实施性（对比度、焦点可见性、拖拽替代）
• 把 WCAG 转译为可测试的工程验收项

WCAG 2.2 按 A/AA/AAA 分级：AA 是主流合规目标（法律与采购要求通常指向 AA），AAA 是增强目标，部分准则（如 7:1 对比度、更严的焦点可见性、拖拽操作的替代）在真实产品中难以全量满足且可能牺牲设计自由度。工程价值：把"无障碍"转译为可测试的成功准则——AA 层落实为对比度 4.5:1、焦点可见（2.4.7 焦点外观）、目标尺寸 24x24、拖拽有替代路径、帮助机制可达等可自动/半自动验收项；AAA 用于关键路径或明确目标人群（如政府站点）的增量增强。取舍原则：默认达成 AA 并纳入 CI 门禁，AAA 按成本效益选择适用场景，记录豁免理由而非静默放弃。

考察 WCAG 分级合规的工程落地：AA 为默认目标与可测试转译、AAA 按场景增强，答案需体现合规与产品现实的平衡。

• 角色（role）、状态（aria-*）与属性的适用场景
• 命名（accessible name）与描述（aria-describedby）的计算
• 常见 ARIA 误用与最小化原则

ARIA 用于"增强而非替换"：role 定义语义角色（dialog、tablist、alert），aria-* 表达状态与关系（aria-expanded、aria-controls、aria-labelledby）。实战要点：可访问名称优先用原生（label、alt、标题文本），不足时用 aria-labelledby/aria-label；复杂描述用 aria-describedby；动态关系用 aria-controls/aria-owns 保持可访问性树一致；状态必须与真实交互同步（展开、选中、禁用）。常见误用：给可交互元素强加错误角色、aria-hidden 包裹可聚焦元素（造成焦点黑洞）、无意义的内联 role（如给 div 加 role="button" 却不实现键盘）、动态内容不播报。原则：优先原生语义，ARIA 最小化，改动即测试。

考察 ARIA 的实践纪律：角色与状态正确映射、命名计算规则、误用识别，答案需强调"原生优先、最小化、可测试"。

• 键盘可达性与焦点可见性的要求
• 焦点管理：进入/移动/归还的完整闭环
• Skip Links 的时机与实现

键盘导航是"不依赖鼠标完成任务"的基础：所有交互元素可达（Tab）、可操作（Enter/Space/方向键）、焦点可见（focus-visible）。Focus Management 的工程价值在于让焦点流动有意义：组件打开时焦点移入（对话框标题、第一个控件）、内部循环（焦点陷阱）、关闭后归还触发元素，避免焦点"丢失"到页面底部。Skip Links（跳转链接）是键盘与屏幕阅读器用户的效率工具：页面顶部提供"跳到主内容"链接，target 指向 main 并配 tabindex="-1" 使可聚焦，激活后焦点移动到内容区且带可见焦点样式。三者的组合保证：首次 Tab 见 Skip Link、组件内焦点闭环、任何时候焦点位置可感知。

考察键盘可访问性的三支柱：可达、可操作、焦点可见，焦点管理的进入-移动-归还闭环与 Skip Link 的工程实现。

• aria-live 的 polite/assertive 优先级与使用场景
• aria-atomic 控制播报粒度
• aria-relevant 控制内容变更的播报类型

aria-live 让动态内容变更被屏幕阅读器自动播报：polite（默认，等当前朗读结束再播）适合大多数通知、进度与结果；assertive 立即打断当前朗读，只用于紧急信息（错误、倒计时警告），滥用会造成朗读风暴。aria-atomic 控制粒度：false（默认）只播变更节点，true 播报整个区域，适合"区域整体语义变化"（如购物车总额）；aria-relevant 限定触发类型：additions/text/removals/all，默认"additions text"，移除非关键内容（如清除提示）可设 additions 避免打扰。工程配置：live 区域预先声明再更新内容（延迟插入动态 node 可能漏播）、用 role="status"（polite）/role="alert"（assertive）语义化封装、更新用整段替换保证文本化播报。

考察 live region 的精确配置：优先级选择、原子性与相关性的组合决定播报体验，答案需给出场景化配置与更新时序。

• 焦点陷阱的循环逻辑（首尾环绕）
• 打开/关闭时的焦点移入与归还
• escape 关闭与 aria-modal 语义

焦点陷阱实现：对话框打开时记录 document.activeElement，焦点移入对话框（首个可聚焦元素）；监听 Tab/Shift+Tab 在对话框内循环——焦点在最后一个元素按 Tab 时回到第一个（反向同理），防止焦点逃逸到背景；推荐用"可聚焦元素收集 + 边界拦截"或 inert 背景（现代浏览器将背景置 inert 即可天然隔离 Tab 顺序）。焦点恢复：关闭时把焦点归还给打开前的触发元素（或按需求归还到指定元素），保证键盘用户焦点不丢失。escape 键监听关闭对话框并归还焦点；配合 aria-modal="true"、role="dialog" 与 aria-labelledby 声明语义。工程注意：动态内容（懒加载选项）后需重新计算可聚焦集合，焦点元素隐藏时跳过。

考察模态对话框的焦点契约：陷阱循环、进入与归还、escape 关闭三位一体，答案需覆盖边界元素处理与语义声明。

• 原生元素自带的角色、键盘与状态语义
• ARIA 只补语义不补行为的局限
• 替代判断：功能匹配 → 原生优先 → ARIA 增强

原则内核：ARIA 只修改可访问性树的语义，不自动提供键盘行为、焦点管理与状态同步，错误使用反而产生"语义与行为分裂"的更坏结果。工程判断流程：先看功能是否有原生元素——按钮用 button（自带 Enter/Space 与焦点）、开关用 input type="checkbox"（自带 toggle 语义）、列表/菜单用原生或 dialog 用原生 ；原生元素无法满足需求时（复杂树形网格、自定义组件）才上 ARIA，且必须补齐键盘契约、焦点管理与状态。坏 ARIA 的典型：div+role="button" 无键盘实现、aria-checked 状态不同步、用 role 掩盖不可聚焦交互。结论：能原生则原生，ARIA 用于"原生没有的语义"，并承担完整实现成本。

考察无障碍的取舍智慧：原生语义自带行为、ARIA 只补语义不补行为，答案需给出"功能匹配→原生优先→ARIA+契约"的判断流程。

• axe-core 能自动检测的规则类别（对比度、ARIA 属性、标签）
• 无法自动化的语义问题（命名质量、顺序、朗读流、真实用户感受）
• 自动化 + 人工审计 + 屏幕阅读器实测的分工

axe-core 能可靠自动化的部分：静态可检测规则——颜色对比度、ARIA 属性合法性、标签缺失、表单关联、文档结构（标题层级）、aria-hidden 与焦点冲突等，覆盖率约 30-50%。无法覆盖的语义问题：可访问名称是否"有意义的自然语言"（标签为"按钮1"则通过但很差）、朗读顺序是否符合预期、组件交互的键盘体验（axe 无法模拟真实 Tab 流程）、焦点管理的行为正确性、以及与特定屏幕阅读器（NVDA/VO/Orca）的实际兼容。因此分工：CI 自动扫描做"基线防回归"（失败即阻断），人工审计覆盖交互流与语义质量，屏幕阅读器实测（+键盘遍历）验证真实用户体验，三者结合才构成完整质量闭环。

考察 a11y 测试的边界认知：自动化覆盖可检测规则、语义质量与朗读流需人工与实测，答案需给出分工与流程。

• 颜色对比度标准与色弱感知的差异
• 不依赖颜色的信息传达（图形+文本双通道）
• prefers-reduced-motion 的动效降级策略

三个层面：对比度——正文 4.5:1、大字/UI 组件 3:1（WCAG），需在设计系统层面定义 token 并自动校验，暗色/亮色主题分别测试；色弱——红绿色弱最普遍，信息不得仅靠颜色区分（图表用图案+标签双通道、状态用图标+文字+颜色），测试用模拟滤镜（如 Sim Daltonism、devtools 模拟）走查；动效——prefers-reduced-motion: reduce 时关闭/减弱非必要动画（位移、缩放、自动轮播），保留功能性过渡（状态反馈），实现用 CSS 媒体查询与 JS matchMedia 双通道，关键路径禁用大位移动画并保证内容可读。工程化：对比度进 CI、色弱走查进评审清单、动效降级作为组件默认能力。

考察感知无障碍的工程落地：对比度 token 化、多通道信息传达、动效媒体查询降级，答案需覆盖三者的系统化实施。

• axe-core 的规则集与运行方式（页面级/组件级）
• 手动验证的清单（键盘、焦点、语义、实测）
• 自动化与手动的触发时机与覆盖互补

axe-core 自动扫描：以规则引擎在页面/组件运行（浏览器扩展、@axe-core/playwright 或 jest-axe），覆盖标签、对比度、ARIA、结构等可判定规则，适合 CI 门禁与组件测试，特点是快速、可重复、但只看"规则"不看"体验"。手动验证：键盘全程可达（Tab 流、方向键、焦点可见）、焦点管理（移入/归还/陷阱）、屏幕阅读器朗读流（NVDA/ChromeVox/VO 实测）、真实任务完成路径（注册、购物、搜索），覆盖自动化无法判定的语义质量与交互行为。配合方式：CI 自动扫描防回归（任何新代码不得新增规则违规），发布前人工清单走查关键流程，组件库配套 axe 单测 + 定期全站扫描 + 实测周期。

考察 a11y 测试体系：自动化管规则基线、手动管体验质量，答案需给出两者在 CI、组件、发布周期的配合模型。

• 三类工具的能力差异与互补
• CI 集成模式（组件级/页面级/预算门禁）
• 结果分级与防回归策略

工具定位：axe-core 是规则引擎，适合组件级单测与页面级扫描（Playwright 注入），粒度细、速度快；Lighthouse A11y 审计（分数与逐项规则）适合性能+A11y 综合预算的门禁场景；Pa11y 专注页面级可访问性检查（HTML 合规、WCAG 规则），适合定期全站爬取。CI 集成模式：单元/组件测试层挂 jest-axe 或 axe-core 注入（每次提交）；E2E 层在关键流程页面跑 @axe-core/playwright 断言零严重违规（PR 门禁）；定时任务用 Pa11y 或 Lighthouse CI 全站扫描并生成趋势报告。策略：把"新增违规"作为阻断项（diff 阈值）、把"总量"作为趋势指标，避免存量违规阻塞迭代——先清存量、再守增量。

考察 a11y 工具的 CI 工程化：按层级选择工具、PR 门禁与趋势报告的配合、存量与增量治理，答案需给出集成拓扑。

• 三者的定义与用途（公开承诺、合规文档、评审记录）
• 声明与实测的一致性
• 版本化维护与责任归属

Accessibility Statement（无障碍声明）是面向用户的公开承诺：说明产品的无障碍支持范围、已遵循标准（WCAG 级别）、已知限制、联系渠道与改善时间表，是法律与信任层面的"对外契约"；VPAT（Voluntary Product Accessibility Template）是按标准模板逐条款填写"支持/部分支持/不支持"的合规自评文档，政府采购与 B2B 招标常要求；ACR（Accessibility Conformance Report）即填写完成的 VPAT 报告，作为对外交付物。工程价值：三者为无障碍工作建立"声明-证据-承诺"闭环——声明基于实测而非愿景，VPAT/ACR 由开发、测试、产品共同维护并随版本更新；维护要点：与测试报告、缺陷记录联动，版本化管理，明确"承诺级别"（如 AA）与豁免项及理由。

考察无障碍合规文档体系：声明是承诺、VPAT/ACR 是证据化自评，答案需说明三者联动与版本化维护。

• 焦点顺序、可见性与语义一致
• 组件交互的键盘契约（方向键、快捷操作）
• tabindex 的正确使用与焦点拦截

工程实践要点：焦点顺序与视觉/DOM 顺序一致（重排布局时校验 Tab 流）、焦点可见（focus-visible 显式样式，不要全局 outline: none）、tabindex 纪律——交互元素用原生（自动入 Tab 序），tabindex="0" 用于给非交互元素补焦点、"-1" 用于编程聚焦（跳转目标、容器），避免滥用正值打乱顺序；组件键盘契约：手风琴用 Enter/Space 切换 + 方向键在面板间移动、树形组件方向键导航 + 左右展开收起、滑块方向键调节，每个自定义组件都要定义并实现契约；焦点管理事件流：打开移入、关闭归还、动态内容插入后的焦点处理，配合 aria 状态同步。

考察键盘与焦点的工程实现面：顺序/可见性/tabindex 纪律、组件键盘契约、焦点事件流，答案需覆盖实践要点与常见错误。

• 对比度标准的计算与分级（4.5:1/3:1）
• 视觉障碍类型（低视力、色弱、明暗敏感）的适配
• 对比度 token 与自动校验

对比度工程化：按 WCAG 计算前景/背景的对比度比——正文 4.5:1、大字与大图形 3:1、UI 组件状态也需 3:1；设计系统用对比度 token 管理（语义色对 + 自动计算），组件开发时用工具（axe、浏览器计算）自动校验，暗色主题与高对比度模式（forced-colors）单独验证。视觉障碍适配：低视力——提供字号缩放（rem 布局）与放大不破版、支持系统字体放大；色弱——多通道信息（图标+文字+颜色）、可调色板；明暗敏感——跟随系统深色模式、避免高亮度闪烁；对比度不足场景提供主题切换。测试：模拟滤镜（色弱）、zoom 200%、forced-colors 走查进清单。

考察视觉无障碍的工程落地：对比度 token 化与自动校验、多类型障碍的适配策略、测试矩阵。

• 扫描的接入点（组件单测、E2E、全站）
• 规则分级与阻断策略
• 扫描结果的可追溯与趋势

CI 中 axe 扫描分三层：组件层——jest-axe 在组件渲染后断言（每个组件提交即验证自身规则）；页面层——@axe-core/playwright 在 E2E 关键流程（注册、支付、搜索）扫描并断言严重/临界违规为零；全站层——定时任务爬取主要路由扫描并输出报告。设计要点：规则按严重度分级，阻断项是"新增违规"而非"存量违规"（先建基线、再守增量）；扫描结果关联 CI artifact 与缺陷跟踪（违规 JSON 自动提 issue）；与 browserslist 一致的真实渲染环境（含移动视口）；配合 Lighthouse CI 的 A11y 分数预算。这样把无障碍变成"每次提交可验证"的质量属性。

考察 CI 无障碍门禁：三层扫描拓扑、增量阻断策略、结果追溯，答案需给出可执行的集成设计。

• 语义与结构检查（元素选择、标题层级、地标）
• 交互与状态检查（键盘、焦点、ARIA 状态）
• 视觉与内容检查（对比度、缩放、动效）

组件级评审清单按维度组织：语义结构——组件选型是否有原生替代（button/select/dialog）、标题层级与地标是否合理、可访问名称是否自然（标签文本 vs aria-label）；交互——键盘全流程可达（Tab 序、方向键、Enter/Space 触发）、焦点可见且位置合理、焦点进入/归还闭环、状态（选中/展开/禁用）与 aria-* 同步；视觉——对比度达标（常态+悬停+禁用）、200% 缩放与重排不破版、动效有 reduce 降级、内容不依赖颜色；内容——错误提示关联输入框（aria-describedby）、动态更新进 live region、文案可被朗读理解。清单应在组件"设计完成、开发前"评审，配合开发中的自动化验证闭环。

考察设计阶段的无障碍评审：语义、交互、视觉、内容四维清单，答案需说明评审时机与自动化闭环。

• 焦点顺序跟随 DOM 而非视觉顺序的机制
• CSS order/flex/grid 重排造成的顺序错位
• 修复策略：结构优先、源码顺序调整、视觉重排受限

键盘 Tab 顺序按 DOM 顺序（实际源码顺序）而非视觉顺序，CSS order（flex/grid 项目重排）、flex-direction: row-reverse、grid 区域摆放都会让视觉顺序与 DOM 顺序脱节，造成"屏幕上按顺序、Tab 却在跳"的错乱。修复策略优先级：优先调整 DOM 结构使源码顺序 = 视觉顺序（这是唯一根治）；视觉重排只用于装饰性元素（不承载交互）；必须重排交互内容时，评估能否用 direction 或网格模板替代 order，实在无法避免则明确接受并做键盘实测（多数场景应拒绝）。自动化防护：用脚本对比"视觉位置序列"与"DOM 顺序"输出差异，纳入组件测试。

考察视觉重排与焦点顺序的冲突机制：Tab 序绑定 DOM 序，order 类重排产生错乱，答案需给出结构调整优先的修复顺序与验证手段。