无障碍标准基础 - 面试题

#

★★★

1. WCAG 3.0（草案）色彩对比 APCA 算法与 4.5:1/3:1 的差异

问题

请解释 WCAG 3.0 草案中采用的 APCA（Accessible Perceptual Contrast Algorithm）色彩对比算法，与 WCAG 2.x 的 4.5:1/3:1 对比度公式相比有哪些本质差异？

考察点

APCA 算法的原理与感知对比度模型
WCAG 2.x 与 WCAG 3.0 对比度标准的差异
对前端色彩设计实践的影响

答案

WCAG 2.x 使用相对亮度（relative luminance）计算对比度比值，公式为 (L1+0.05)/(L2+0.05)，阈值是 4.5:1（正文）和 3:1（大号文本/图形）。WCAG 3.0 草案引入 APCA，它基于人体视觉感知模型，考虑了字体大小、字重、颜色在感知空间中的距离，还与内容复杂程度、周围环境亮度相关。APCA 的数值范围大致在 -100 到 100，不再使用固定比值，而是根据文本大小和字重给出不同阈值（如正文小字约 75-90）。差异在于：APCA 更符合感知均匀性，对深色背景上的浅色文字计算更合理，并对"大且粗"的文字给予更宽松的阈值。

解析

传统 WCAG 对比度公式在深色背景下常出现过富余或过紧缺的问题，APCA 通过感知空间计算"感知亮度差"，使对比度评估更接近真实视觉感受。理解这一演进有助于前端在不同标准下做色彩决策，也是说明"无障碍标准是持续迭代"的典型例子。

#

★★★

2. WCAG 2.2（新增 9 条准则）在前端的工程价值与现代表单/焦点

问题

WCAG 2.2 新增了 9 条无障碍准则，它们在前端工程中对应哪些具体的实现要求，尤其是在表单与焦点交互方面？

考察点

WCAG 2.2 新增准则的理解
焦点可见性、目标尺寸等新要求
与前端的工程映射

答案

WCAG 2.2（2023 年发布）新增了 9 条准则，包括：Focus Not Obscured (2.4.11)、Focus Appearance (2.4.13)、Dragging Movements (2.5.7)、Target Size (Minimum) (2.5.8)、Consistent Help (3.2.6)、Redundant Entry (3.3.7)、Accessible Authentication (3.3.8) 等。工程上要求：焦点环不被遮挡、焦点可见指示足够醒目、可点击目标最小 24×24 CSS 像素、支持除拖拽外的替代操作、登录认证不依赖认知能力（如验证码）等。对表单与焦点的直接影响是：开发自定义控件时需保证焦点不被固定页头/弹层遮挡，提供清晰的 focus 指示，并让表单每步不必重复输入。

解析

WCAG 2.2 把这些"历史上被忽略但影响真实用户"的问题固化为可测标准，促使前端把焦点可见性、目标尺寸当作一等公民来设计，而不是事后补丁。掌握新增准则能在评审中快速定位合规点。

#

★★★

3. 键盘导航（tabindex、focus-visible）与 Tab 顺序设计

问题

如何通过 tabindex 和 focus-visible 设计键盘导航与 Tab 顺序，使页面对所有键盘用户可达？

考察点

tabindex 的合法值（0、-1、正整数）及其语义
:focus-visible 与 :focus 的区别
Tab 顺序的自然 DOM 顺序原则

答案

tabindex=0 让元素可聚焦并进入自然 Tab 顺序；tabindex=-1 让元素可编程聚焦（调用 focus()）但不进入 Tab 顺序；正整数值会打乱自然顺序，应尽量避免。理想的 Tab 顺序应遵循 DOM 语义顺序，即视觉顺序与 DOM 顺序一致。:focus-visible 只在键盘导航（非鼠标点击）时显示焦点环，避免鼠标点击时出现"多余"的焦点样式，而 :focus 在所有聚焦时都触发。按钮、链接、表单控件等原生可聚焦元素无需额外 tabindex，自定义控件（如 div 模拟的按钮）则需 tabindex=0 并处理键盘事件。

解析

键盘导航是无障碍的基础。正确使用 tabindex，并结合 :focus-visible 提供只在键盘操作时可见的焦点指示，既能满足无障碍又不破坏鼠标用户体验。这是"语义化 + 渐进增强"的典型实践。

示例代码

<button>原生按钮自动可聚焦</button>
<div role="button" tabindex="0" onclick="...">自定义按钮</div>

:focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; }

#

★★

4. WCAG 的四大原则，可感知、可操作、可理解、健壮？

问题

请解释 WCAG 的四大原则（POUR）——可感知、可操作、可理解、健壮，并说明它们各自涵盖哪些内容？

考察点

四大原则的含义
各原则下的典型准则
对无障碍设计的意义

答案

WCAG 的四大原则是：可感知（Perceivable）——信息必须能通过用户的感官呈现，涉及文本替代、时间媒体、可适应、可区分（如对比度）；可操作（Operable）——界面必须能被键盘和所有输入方式操作，涉及键盘可达、足够时间、防癫痫、可导航、输入方式；可理解（Understandable）——信息与操作必须可理解，涉及可读语言、可预测、输入辅助；健壮（Robust）——内容必须能被各种用户代理（包括辅助技术）可靠解析，涉及兼容性、可解析、名称/角色/值。每个原则下再细分可测试的成功标准（A/AA/AAA 等级）。

解析

POUR 是无障碍的顶层框架，任何无障碍问题都能归类到四大原则之一。面试中阐述 POUR 及各原则对应的典型成功标准，能体现系统化的无障碍认知。

#

★★

5. 键盘可达性，Tab 顺序、焦点管理与跳过链接？

问题

如何实现键盘可达性，包括恰当的 Tab 顺序、焦点管理与跳过链接（skip link）？

考察点

自然 Tab 顺序与焦点管理
跳过链接的作用与实现
焦点陷阱与焦点恢复

答案

键盘可达性要求所有功能只能通过键盘完成。Tab 顺序应遵循合理的 DOM 顺序，通过 tabindex 控制自定义控件。焦点管理包括：打开模态框时把焦点移入并限制在框内（焦点陷阱），关闭时把焦点归还到触发元素；动态内容（如路由切换）后把焦点移到新标题或内容区。跳过链接（skip link）是页面顶部的一个"跳到主内容"链接，让键盘与读屏用户跳过冗长的导航区，直接到达主要内容。实现上用 <a href="#main"> 配合 <main id="main" tabindex="-1">，并处理好焦点定位。

解析

键盘可达性是障碍（尤其对视觉与运动障碍用户）的核心。跳过链接解决"重复导航"问题，焦点管理保证操作上下文不丢失，这三者共同构成键盘导航的完整闭环。

示例代码

<a class="skip-link" href="#main">跳到主内容</a>
<header>...</header>
<main id="main" tabindex="-1">...</main>

#

★★

6. WCAG 2.2 的 Target Size (Minimum) 与 Focus Not Obscured，24×24 CSS 像素的达标规则、例外（inline 文本）与实现要点？

问题

请解释 WCAG 2.2 的 Target Size (Minimum) 与 Focus Not Obscured（Minimum）两则准则，包括 24×24 CSS 像素的达标规则、inline 文本例外及实现要点？

考察点

Target Size 24×24 CSS 像素规则
inline 文本例外
Focus Not Obscured 的含义

答案

Target Size (Minimum)（2.5.8）要求可点击目标的最小尺寸为 24×24 CSS 像素，除非：目标在 inline 文本中（如正文链接）、由浏览器/UA 控制（如原生控件）、目标很小但有足够大的间距保证不易误触、或目标等价的替代目标足够大。Focus Not Obscured (Minimum)（2.4.11）要求当元素获得焦点时，焦点指示不被其他内容（如粘性页头、弹层、cookie 横幅）完全遮挡。实现要点：用 padding 扩展可点击区域到 24×24，避免用固定定位元素覆盖焦点，或用 :focus-within 处理容器焦点。

解析

这两条是 WCAG 2.2 强调"移动端真实可用性"的体现。24×24 旨在减少误触（尤其触屏用户），Focus Not Obscured 保证键盘用户能看到焦点去向。构造点击区时用 CSS 的 padding + 伪元素是常见工程手法。

#

★★

7. 可访问名称计算（accessible name computation），aria-labelledby、aria-label、内容文本与 title 的优先级，以及常见命名缺失问题？

问题

请解释可访问名称计算（accessible name computation）的优先级规则，以及常见命名缺失问题？

考察点

name computation 的优先级顺序
aria-labelledby、aria-label、内容文本、title 的关系
常见命名缺失的误区

答案

可访问名称（accessible name）是辅助技术读取元素时使用的名称。计算的优先级大致为：aria-labelledby（最高）> aria-label > 原生标签/内容文本（如 label 元素、button 的文本内容、img 的 alt）> title/placeholder 等。例如 <button aria-labelledby="x"> 优先于 aria-label，再优先于 button 文本。常见命名缺失问题：只用装饰性图片但缺失 alt、表单控件没有 label、icon-only 按钮没有 aria-label、div 模拟控件没有可访问名称、title 在触屏上不可见不宜作为唯一命名来源。

解析

可访问名称是"名称/角色/值"（Name, Role, Value）的基础。命名不足会导致读屏用户无法识别控件用途。掌握优先级能让开发者判断"为什么我的 aria-label 没生效"这类问题。

#

★★

8. ARIA 语义（roles、properties、states）

问题

请解释 ARIA 的语义体系，包括 roles、properties、states，以及它们如何用于增强自定义组件的可访问性？

考察点

ARIA 的 role、property、state 三要素
如何用 ARIA 补充语义
不滥用 ARIA 的原则

答案

ARIA（Accessible Rich Internet Applications）包含三类：roles（角色，如 role="button"、role="dialog"、role="tablist"）、properties（属性，如 aria-label、aria-describedby、aria-labelledby）、states（状态，如 aria-expanded、aria-hidden、aria-disabled）。ARIA 能让原本无语义的 div 拥有角色、属性与状态，使辅助技术能正确解析。但 ARIA 的原则是"如果原生 HTML 已具备语义，则优先用原生元素"；ARIA 只应补充原生无法表达的语义，且不改变浏览器渲染行为，只影响可访问性语义树。

解析

ARIA 是自定义组件的"无障碍语义层"。理解 role/property/state 三者的区别与使用时机，是避免"ARIA 地狱"（过度使用导致混乱）的关键。核心准则是优先原生语义，ARIA 仅在需要时补充。

#

★★

9. WCAG 标准与合规等级（A/AA/AAA）

问题

请解释 WCAG 的合规标准与 A/AA/AAA 三个等级的含义及适用场景？

考察点

A/AA/AAA 三个等级的含义
常见合规目标（AA）
等级与实现成本的关系

答案

WCAG 每个成功标准（成功准则）都标注一个合规等级：A（最基本，必须满足）、AA（推荐，多数组织与法规要求）、AAA（最高，可选，部分对特定用户群体很关键）。绝大多数企业、政府网站与无障碍法规（如 ADA、欧洲 Accessibility Act）以 AA 为准。AAA 通常很严格，甚至可能与某些设计冲突（如要求更极端的对比度、禁止某些动画），因此很少作为全面强制目标，而是作为特定内容（如视频字幕）的增强。合规判定需声明的范围：整个页面、页面的一部分、或完整流程。

解析

等级体系让无障碍要求可量化、可审计。工程上通常以 AA 为基线嵌入 CI，把 AAA 作为增强项。回答时说明"AA 是常见合规基线"能体现对行业实践的把握。

#

★★

10. 焦点陷阱（Focus Trap）在模态框的应用

问题

请解释焦点陷阱（Focus Trap）在模态框中的实现原理与注意事项？

考察点

焦点陷阱的原理
模态框打开/关闭时的焦点管理
实现要点与边界

答案

焦点陷阱指在模态框或弹层打开时，把 Tab 焦点限制在该容器内循环，防止用户 Tab 到背景页面。实现方式：打开时把焦点移到第一个可聚焦元素（或容器），监听 Tab/Shift+Tab 键，在焦点到达容器内最后一个元素时循环回第一个；同时用 aria-modal="true" 或背景 inert 化（如 inert 属性）让背景不可聚焦。关闭时必须把焦点归还到打开模态框的触发控件，否则键盘用户会"迷失"。还要处理 Esc 关闭、避免焦点被陷阱困住（如提供关闭按钮）。

解析

焦点陷阱是模态框可用性的关键。只有"把焦点限制在框内"且"关闭后归还焦点"双管齐下，才能保证键盘与读屏用户不迷失。现代浏览器支持 inert 属性，简化了背景不可交互的实现。

示例代码

function openModal() {
  const modal = document.getElementById('modal');
  modal.setAttribute('aria-modal', 'true');
  firstFocusable.focus();
  document.addEventListener('keydown', trapFocus);
}

#

★★

11. title/role/aria-* 与 data-* 属性在 Web Components 命名空间的工程取舍

问题

在 Web Components 中，title、role、aria-* 与 data-* 属性在命名空间与工程使用上有哪些取舍？

考察点

标准属性与自定义属性的区别
data-* 与 aria-* 的作用域
Web Components 中的无障碍属性传递

答案

title、role、aria-* 是标准 HTML 属性，会被浏览器与辅助技术解析；data-* 是开发者自定义数据属性，仅用于存储数据，不参与可访问性语义。在 Web Components 中，自定义元素默认不继承宿主的不透明属性，需要显式把 role、aria-* 等"反射"到内部可访问性相关元素上，或用 ElementInternals 的 setAttribute/states 暴露给辅助技术。工程取舍：title 因触屏不可见、且读屏支持不一，不宜作为唯一可访问名称来源；data-* 不应承载无障碍语义；role/aria-* 应审慎使用，避免与内部原生语义冲突。

解析

Web Components 的封装性使无障碍属性传递成为专门问题。理解 aria-* 与 data-* 的语义边界，以及用 ElementInternals 暴露内部语义，能避免"组件内部无障碍但宿主不可见"的坑。

#

★★

12. WCAG 2.1/2.2 的四大原则（POUR），可感知、可操作、可理解、健壮，各对应哪些具体标准？

问题

请详细说明 WCAG 2.1/2.2 的四大原则（POUR）分别对应哪些具体准则与成功标准？

考察点

四大原则的完整映射
各原则下的代表性成功标准
POUR 与工程实践的联系

答案

可感知（Perceivable）对应准则 1.1 文本替代（alt）、1.2 时间媒体（字幕、音频描述）、1.3 可适应（语义结构、信息与关系）、1.4 可区分（对比度、颜色使用、重缩放）。可操作（Operable）对应 2.1 键盘可达、2.2 足够时间、2.3 防癫痫、2.4 可导航（标题、焦点、跳转链接）、2.5 输入方式（指针、拖拽、目标尺寸）。可理解（Understandable）对应 3.1 可读语言、3.2 可预测（一致导航、焦点顺序）、3.3 输入辅助（错误识别、标签、帮助）。健壮（Robust）对应 4.1 兼容性（可解析、名称/角色/值）。WCAG 2.2 在这些基础上新增了 Focus Appearance、Target Size、Dragging Movements 等。

解析

把 POUR 与具体标准编号一一对应，能体现对规范的系统掌握。面试中能说出"对比度属于 1.4.3 可区分"这类映射，比泛泛而谈更有说服力，也便于指导工程落地。

#

★★

13. ARIA 的角色与属性，role/state/property 如何正确使用，ARIA 误用的常见反模式？

问题

请说明 role、state、property 如何正确使用，以及 ARIA 误用的常见反模式？

考察点

role/state/property 的正确用法
常见 ARIA 反模式
优先原生语义

答案

role 定义元素语义角色（如 button、tab、dialog），state/property 描述状态（如 aria-expanded、aria-checked）与属性（如 aria-label、aria-controls）。正确使用：只给没有原生语义或需要改变语义的元素加 role；用 state 表达可变化的状态；用 property 补充信息。常见反模式：给原生元素加与原生语义冲突的 role（如给 <button> 加 role="heading"）、滥用 aria-label 覆盖原生文本、过度使用 role 使简单面板失去简单语义、把 aria-hidden 用在可聚焦元素上、用 aria- 属性替代原生控件而不处理键盘行为。

解析

ARIA 的"第一规则"是不要滥用 ARIA。正确做法是"先原生、后 ARIA"，且用了 ARIA 就必须同步实现其语义要求的行为（键盘、焦点、状态更新）。识别反模式能避免无障碍反而被 ARIA 破坏。

#

★

14. tabindex=-1/skip-link/landmark/focus-visible 跳到主内容（Skip to Main）

问题

请解释如何用 tabindex=-1、skip-link、landmark 与 focus-visible 实现"跳到主内容"（Skip to Main）导航？

考察点

skip-link 的作用与实现
tabindex=-1 在跳转中的应用
landmark 与 focus-visible 的配合

答案

Skip to Main 是页面顶部"跳到主内容"的链接，让键盘/读屏用户跳过导航直达正文。实现：<a href="#main" class="skip-link">跳到主内容</a>，主内容块 <main id="main" tabindex="-1">。关键在于 <main> 需要 tabindex="-1" 使焦点能被编程移入（因为 main 默认不可聚焦），这样跳转后焦点真正落在主内容，读屏才会从那里开始朗读。同时 <main> 等 landmark 元素让读屏用户能直接通过地标导航。:focus-visible 用于保证跳转后焦点指示可见但不影响鼠标体验。

解析

跳转链接的常见错误是"href 指向了 id 但 main 不可聚焦导致焦点没移动"。给目标加 tabindex="-1" 是让焦点编程聚焦的关键。landmark 语义 + skip link + focus-visible 三者结合，是"可导航"原则的完整工程实践。

示例代码

<a class="skip-link" href="#main">跳到主内容</a>
<main id="main" tabindex="-1">...</main>

#

★

15. 无障碍的验收，自动化扫描（axe）+ 手动键盘测试 + 屏幕阅读器（NVDA/VoiceOver）的分层策略？

问题

请说明无障碍验收的分层策略：自动化扫描（axe）、手动键盘测试与屏幕阅读器（NVDA/VoiceOver）测试如何配合？

考察点

分层测试策略
各层的覆盖范围与局限
不同层级的配合时机

答案

无障碍验收应分层进行：第一层是自动化扫描（axe-core、Lighthouse、Pa11y），能快速发现约 30-40% 的问题（如缺失 alt、对比度、ARIA 错误），可嵌入 CI 与单测；第二层是手动键盘测试，验证 Tab 顺序、焦点可见性、skip link、焦点陷阱、所有交互能否仅用键盘完成；第三层是屏幕阅读器测试（NVDA/VoiceOver），验证真实读屏体验、live region 播报、可访问名称等自动化无法覆盖的语义。三层互补：自动化快但浅，手动键盘验证交互，读屏验证最终体验。

解析

单一自动化工具无法覆盖全部无障碍，分层策略保证了"自动化兜底 + 人工验证关键体验"。这是面试中体现成熟工程思维的点：自动化扫到的先修，再人工聚焦交互与读屏。

#

★

16. ARIA 的角色与属性，何时需要、何时避免过度？

问题

请说明何时需要添加 ARIA 角色与属性，何时应避免过度使用？

考察点

需要 ARIA 的场景
过度使用 ARIA 的反模式
原生优先原则

答案

需要 ARIA 的场景：自定义组件没有原生语义（如用 div 构建的 tab、dialog、slider、combobox）、需要补充状态（aria-expanded、aria-current）、需要关联说明（aria-describedby）、需要给无文本控件命名（aria-label）。应避免过度使用的场景：原生元素已具备语义（如 button、nav、input）时无需再叠加 ARIA；用 aria-label 覆盖有意义的原生文本；给静态内容加复杂 role；用 role 改变原生语义而破坏默认行为。ARIA 是"补充剂"而非"必加项"，过度 ARIA 反而增加读屏负担。

解析

判断"何时需要 ARIA"的核心是"原生 HTML 是否已表达该语义"。能用原生就用原生，ARIA 只在原生表达不了时补充。这既是工程最佳实践，也是 WCAG"健壮"原则的要求。

#

★

17. 语义化 HTML 与无障碍，正确的标签优于 ARIA？

问题

为什么说"正确的语义化 HTML 标签优于 ARIA"？请举例说明？

考察点

原生语义元素的功能
语义化 HTML 与 ARIA 的关系
原生元素自带的键盘/焦点行为

答案

原生语义化 HTML 元素（如 <button>、<a>、<nav>、<main>、<label>、<table>、<select>）自带正确的语义、键盘行为、焦点管理、状态播报，且免费获得浏览器支持。而 ARIA 只改变语义，不带来任何行为——用 <div role="button"> 需要开发者手动实现 Tab 聚焦、Enter/Space 触发、点击回调等。因此"用对原生标签"既省代码又更健壮。只有原生无法表达时（如自定义 combobox、复杂 dialog）才用 ARIA 补充。ARIA 可修"语义的错"，但修不了"行为缺失"。

解析

这一原则（"First Rule of ARIA"）是前端无障碍的基石。原生元素"语义 + 行为 + 状态"一体，ARIA 只补语义。回答时强调"原生优先、ARIA 补充"既体现规范理解，也体现工程智慧。