可访问性（a11y）面试题

本题库共收录 59 道面试题（基础 17 / 进阶 22 / 深入 13 / 架构 7）。本文件收录 Web 可访问性（a11y）相关面试题，目标题量 30 道。题型覆盖：概念题、代码分析题、手写代码题、场景设计题、系统设计题、综合开放题、软技能题。难度覆盖：基础、进阶、深入、架构。

基础题（12 道）

FB-07-CO-B-001：什么是语义化 HTML？它对可访问性有什么价值？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：语义化 HTML、Landmarks、屏幕阅读器、可访问性、SEO 出现频率：高频 预计回答时长：2-3 分钟

题目描述：请解释“语义化 HTML”的含义，并举例说明 <header>、<nav>、<main>、<section>、<article>、<aside>、<footer> 等标签在可访问性中的作用。

参考答案：

语义化 HTML 是指根据内容含义选择恰当的标签，而不是全部使用 <div> / <span> 来堆砌页面。

对可访问性的价值：

构建页面结构（Landmarks）：
- <header>、<nav>、<main>、<aside>、<footer> 等标签会被浏览器隐式映射为 ARIA landmark roles（banner、navigation、main、complementary、contentinfo）。
- 屏幕阅读器用户可通过快捷键在这些 landmark 之间快速跳转，提升浏览效率。
标题与文档大纲：
- 正确的标题层级（<h1> ~ <h6>）形成文档大纲，帮助辅助技术理解信息层级。
默认交互行为：
- <button>、<a>、<input> 等原生控件自带键盘可访问性、焦点管理和屏幕阅读器支持，无需额外实现。

最佳实践：能用原生语义标签解决的问题，不要先用 ARIA；避免“div 汤”。

评分维度：

语义化 HTML 概念准确性（30%）
常见语义标签对应的 landmark / 默认 role（40%）
能说明对屏幕阅读器和键盘导航的实际收益（30%）

常见错误：

把语义化 HTML 的目的仅说成“SEO”
混淆 <section> 与 <div> 的使用场景
认为给 <div> 加 role 可以完全替代语义标签

延伸追问：

为什么 <nav> 内部通常还要使用 <ul> / <li>？
什么时候用 <article>，什么时候用 <section>？
语义化标签缺失会如何影响 accessibility tree？

相关题目：

FB-07-CO-A-001 ARIA 是什么？何时应该使用 ARIA

参考资源：

口头回答版：

语义化 HTML 是指根据内容含义选择恰当的标签，而不是全部使用 <div> / <span> 来堆砌页面。构建页面结构（Landmarks）： - <header>、<nav>、<main>、<aside>、<footer> 等标签会被浏览器隐式映射为 ARIA landmark roles（banner、navigation、main、complementary、contentinfo）。 - 屏幕阅读器用户可通过快捷键在这些 landmark 之间快速跳转，提升浏览效率。

FB-07-CO-B-002：图片的 `alt` 属性应该怎么写？哪些情况可以留空？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：alt text、图片、屏幕阅读器、装饰图、信息图 出现频率：高频 预计回答时长：2-3 分钟

题目描述：请说明 alt 属性的作用，并给出信息性图片、功能性图片、装饰性图片的写法示例。

参考答案：

alt 为图片提供文本替代，当图片无法加载或被屏幕阅读器读取时，用户能通过 alt 理解图片含义。

信息性图片：alt 应概括图片传达的关键信息。

html

<img src="chart.png" alt="2024 年 Q1 销售额同比增长 23%" />

功能性图片（如图标按钮）：alt 应说明动作或目标，而非图片外观。
html
```
<button><img src="search.svg" alt="搜索" /></button>
```
1
装饰性图片：使用空 alt=""，让屏幕阅读器忽略。
html
```
<img src="decoration.png" alt="" />
```
1
复杂图表 / 流程图：单靠 alt 难以描述清楚时，应提供页面内详细说明，使用 aria-describedby 或 <figure> / <figcaption>。

不要写“图片”“图标”“image_01.png”等无意义文本；也不要在所有图片上堆砌关键词。

评分维度：

说明 alt 对屏幕阅读器用户的作用（30%）
能区分信息性、功能性、装饰性图片（40%）
给出复杂图片的可访问替代方案（30%）

常见错误：

所有图片都填一样的“装饰图”或都不写 alt
把文件名、URL 当作 alt
对需要说明的复杂图表只写一句话 alt

延伸追问：

一个 Logo 链接到首页时，alt 应该怎么写？
<svg> 是否也需要 alt 或 role？
CSS 背景图与 <img> 在可访问性上的区别是什么？

参考资源：

口头回答版：

alt 为图片提供文本替代，当图片无法加载或被屏幕阅读器读取时，用户能通过 alt 理解图片含义。信息性图片：alt 应概括图片传达的关键信息。功能性图片（如图标按钮）：alt 应说明动作或目标，而非图片外观。装饰性图片：使用空 alt=""，让屏幕阅读器忽略。

FB-07-CO-B-003：如何为表单控件提供可访问的标签？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：表单标签、label、aria-label、aria-labelledby、表单可访问性 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明表单控件与标签的关联方式，并解释当页面上没有可见标签时，应该如何处理。

参考答案：

显式 <label>：使用 for 属性关联控件的 id。

html

<label for="email">邮箱</label>
<input id="email" type="email" />

隐式 <label>：将控件包裹在 <label> 内。

html

<label>
  邮箱
  <input type="email" />
</label>

无可见标签时：
- 使用 aria-label 直接提供可访问名称。
- 或使用 aria-labelledby 指向已有文本元素。
分组标签：对于单选框、复选框组，使用 <fieldset> + <legend> 提供分组语义。

placeholder 不能替代 <label>：它在输入内容后会消失，且对比度通常不足，屏幕阅读器支持也不稳定。

评分维度：

说出显式 / 隐式 label 的两种关联方式（40%）
解释 placeholder 不能替代 label 的原因（20%）
说明 aria-label / aria-labelledby 的适用场景（40%）

常见错误：

只把文字放在输入框旁边，但没有与控件关联
依赖 placeholder 作为唯一标签
对图标按钮使用 title 作为唯一可访问名称

延伸追问：

aria-label 与 aria-labelledby 有什么区别？
输入框右侧有一个“显示密码”的图标按钮，如何给它提供可访问名称？
对于单选按钮组，为什么推荐使用 <fieldset> / <legend>？

参考资源：

口头回答版：

显式 <label>：使用 for 属性关联控件的 id。隐式 <label>：将控件包裹在 <label> 内。 - 使用 aria-label 直接提供可访问名称。 - 或使用 aria-labelledby 指向已有文本元素。

FB-07-CO-B-004：键盘导航的基础原则是什么？`tabindex` 如何使用？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：键盘导航、tabindex、focus、交互元素、Tab 顺序 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明网页键盘可访问性的基本要求，并解释 tabindex="0"、tabindex="-1"、tabindex=" >0" 的区别与使用场景。

参考答案：

键盘可访问性原则：

所有可通过鼠标触发的功能，都应能通过键盘完成。
Tab 顺序应与自然阅读顺序（视觉顺序）一致。
焦点当前位置必须可见（focus indicator）。

tabindex 取值：

值	含义	使用场景
未设置	浏览器默认决定	链接、按钮、表单控件等默认可聚焦
`0`	纳入自然 Tab 顺序	自定义交互组件（如自定义按钮、tab）需要键盘聚焦
`-1`	可脚本聚焦，但不纳入 Tab 顺序	模态框、错误汇总、Skip Link 目标等需要 `element.focus()` 聚焦
`>0`	正数，强制改变 Tab 顺序	不推荐，会破坏自然顺序，维护困难

自定义控件加 tabindex="0" 后，还必须处理 Enter、Space、方向键等键盘事件；仅加 tabindex 不等于键盘可用。

评分维度：

阐述键盘可访问的基本原则（30%）
区分三种 tabindex 取值（40%）
说明自定义控件在加 tabindex 后还要做什么（30%）

常见错误：

使用 tabindex 大于 0 来调整 Tab 顺序
给静态文本 / 装饰元素加 tabindex="0"
只加 tabindex 不处理键盘事件和焦点样式

延伸追问：

如何确保 Tab 顺序与视觉顺序一致？
什么是 roving tabindex？在什么组件中使用？
嵌套的 iframe 对 Tab 顺序有什么影响？

相关题目：

FB-07-CO-A-003 焦点指示器如何自定义
FB-07-CD-A-001 手写可访问自定义下拉菜单

参考资源：

MDN - tabindex

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-CO-B-005：颜色对比度对可访问性有什么要求？如何检测？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：颜色对比度、WCAG、contrast ratio、色盲、非文本对比度 出现频率：高频 预计回答时长：2-3 分钟

题目描述：请说明 WCAG 对文本对比度的要求，并介绍常用的检测方法和工具。

参考答案：

根据 WCAG 2.1：

普通文本（18px 以下或 14px 以下粗体）：
- AA 级：对比度至少 4.5:1
- AAA 级：对比度至少 7:1
大号文本（18px 以上或 14px 以上粗体）：
- AA 级：对比度至少 3:1
- AAA 级：对比度至少 4.5:1
非文本对比度（WCAG 2.1 1.4.11）：
- UI 组件边界、图标、图形关键部分与其相邻颜色之间至少 3:1。

不要仅通过颜色传达信息；应配合文本、图标、图案或形状差异。

常用工具：

Lighthouse（Accessibility 审计）
axe DevTools
Colour Contrast Analyser（CCA）
浏览器开发者工具自带的对比度提示
APCA（WCAG 3 方向，更注重视感知）

评分维度：

正确说出 AA 级普通文本与大号文本阈值（40%）
提到非文本对比度 3:1 要求（30%）
能列举 2 种以上检测工具 / 方法（30%）

常见错误：

只测标题，忽略正文、占位符、禁用状态
认为“品牌色”可以豁免对比度要求
仅通过颜色变化表达错误状态

延伸追问：

如果品牌主色对比度不足，前端与设计团队应如何协作？
Dark Mode 下如何保持对比度？
如何处理渐变背景上的文字？

参考资源：

口头回答版：

根据 WCAG 2.1： - 普通文本（18px 以下或 14px 以下粗体）： - AA 级：对比度至少 4.5:1 - AAA 级：对比度至少 7:1

FB-07-CA-B-001：下面这段代码存在哪些可访问性问题？

题型：代码分析题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：代码审查、alt、label、button、focus、链接 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请指出以下代码片段中的可访问性问题，并给出修改建议。

html

<div class="card">
  <img src="product.jpg" />
  <h3>无线耳机</h3>
  <input type="text" placeholder="请输入数量" />
  <div class="btn" onclick="addToCart()">加入购物车</div>
  <a onclick="goBack()">返回</a>
</div>

参考答案：

问题与修复：

图片缺少 alt

html

<img src="product.jpg" alt="白色无线耳机，支持主动降噪" />

输入框没有关联标签，依赖 placeholder

html

<label for="qty">数量</label>
<input id="qty" type="text" placeholder="例如：2" />

“加入购物车”使用 <div> 模拟按钮
- 无法通过 Tab 聚焦，也无法通过 Enter / Space 触发。
- 应改为 <button>：
  html
```
<button class="btn" onclick="addToCart()">加入购物车</button>
```
  1
“返回”使用 <a> 但没有 href
- 无法通过键盘聚焦，也不是真正的链接。
- 如果是页面跳转，应使用 <a href="...">；如果是执行 JS 操作，应使用 <button>。

评分维度：

识别图片与表单的标签问题（40%）
识别自定义按钮 / 伪链接的键盘可访问问题（40%）
给出符合语义化的修复方案（20%）

常见错误：

只发现图片缺 alt，忽略 <div> 按钮和 <a> 无 href
建议给 <div> 加 role="button" 但不处理键盘事件
认为 onclick 绑定在 <a> 上就能当作按钮用

延伸追问：

如果必须使用 <div> 实现按钮，最少需要补哪些 ARIA 和事件？
这个卡片整体是否应被链接 / 按钮包裹？怎么做更合理？

参考资源：

口头回答版：

输入框没有关联标签，依赖 placeholder “加入购物车”使用 <div> 模拟按钮 - 无法通过 Tab 聚焦，也无法通过 Enter / Space 触发。 - 应改为 <button>：

FB-07-CO-B-006：为什么 `placeholder` 不能替代 `label`？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：placeholder、label、表单、可访问性 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请说明在表单控件中，placeholder 为什么不能替代 label，以及正确的做法是什么。

参考答案：

label 是表单控件的永久名称，点击 label 可把焦点移到关联控件，屏幕阅读器会朗读它。
placeholder 只是输入示例或提示，聚焦后可能消失，用户填写时无法回看字段含义。
屏幕阅读器对 placeholder 的支持不如 label 稳定，且低视力用户可能看不清。
正确做法：每个表单控件都使用显式 <label for="id">，placeholder 仅作为输入格式示例，不作为唯一说明。

评分维度：

label 的可访问性作用（40%）
placeholder 的局限性（40%）
最佳实践（20%）

常见错误：

用 placeholder 替代字段标题。
认为 visually hidden 的 label 没有价值。

延伸追问：

如何在设计稿空间不足时兼顾 label 与美观？
浮动标签（floating label）有什么可访问性风险？

相关题目：

FB-07-CO-B-003 如何为表单控件提供可访问的标签
FB-07-SC-A-001 设计一个带错误提示的可访问表单

参考资源：

口头回答版：

label 是表单控件的永久名称，点击 label 可把焦点移到关联控件，屏幕阅读器会朗读它。 - placeholder 只是输入示例或提示，聚焦后可能消失，用户填写时无法回看字段含义。 - 屏幕阅读器对 placeholder 的支持不如 label 稳定，且低视力用户可能看不清。 - 正确做法：每个表单控件都使用显式 <label for="id">，placeholder 仅作为输入格式示例，不作为唯一说明。

FB-07-CO-B-007：如何为表单错误提示提供无障碍支持？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：表单验证、错误提示、aria-invalid、aria-describedby 出现频率：高频 预计回答时长：2-3 分钟

题目描述：请说明在表单验证失败时，如何让错误提示对屏幕阅读器和键盘用户都可感知。

参考答案：

在无效控件上设置 aria-invalid="true"，明确告诉辅助技术当前字段有误。
使用 aria-describedby 把错误信息与输入框关联，焦点进入输入时屏幕阅读器会朗读错误。
错误文本要具体说明出错原因和修正方法，而不是仅显示"输入错误"。
避免仅通过颜色（红色边框）传达错误，应同时提供图标或文字。
提交表单后，把焦点移到第一个错误字段或错误汇总区域。

评分维度：

aria-invalid 使用（30%）
aria-describedby 关联（30%）
错误文本清晰（30%）
不依赖颜色（10%）

常见错误：

仅改变边框颜色表示错误。
错误提示放在输入框下方但没有关联。

延伸追问：

多个错误时，如何设计错误汇总？
实时验证和提交后验证在无障碍上有什么区别？

相关题目：

FB-07-SC-A-001 设计一个带错误提示的可访问表单
FB-07-CO-B-003 如何为表单控件提供可访问的标签

参考资源：

口头回答版：

在无效控件上设置 aria-invalid="true"，明确告诉辅助技术当前字段有误。 - 使用 aria-describedby 把错误信息与输入框关联，焦点进入输入时屏幕阅读器会朗读错误。 - 错误文本要具体说明出错原因和修正方法，而不是仅显示"输入错误"。 - 避免仅通过颜色（红色边框）传达错误，应同时提供图标或文字。

FB-07-CO-B-013：WCAG 的 POUR 四项原则是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：WCAG、POUR、可访问性、原则 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Perceivable、Operable、Understandable、Robust 的含义。

参考答案：

POUR：

Perceivable（可感知）：信息和 UI 组件必须以用户可感知的方式呈现，如替代文本、颜色对比度。
Operable（可操作）：界面组件必须可操作，如键盘导航、充足的时间限制。
Understandable（可理解）：信息和操作必须可理解，如可读文本、错误提示。
Robust（健壮）：内容必须能被各种辅助技术可靠解析，如语义化 HTML。

评分维度：

Perceivable（25%）：可感知
Operable（25%）：可操作
Understandable（25%）：可理解
Robust（25%）：健壮

常见错误：

只关注键盘导航而忽略可感知性
把 POUR 当作设计原则而非可访问性原则
认为 POUR 只适用于视障用户

口头回答版：

POUR 四项原则是可感知、可操作、可理解、健壮，覆盖所有残疾类型和辅助技术。

FB-07-CO-B-014：如何正确使用 heading 层级？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：heading、h1-h6、语义化、屏幕阅读器 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明标题层级对可访问性的影响和常见错误。

参考答案：

页面应只有一个 h1，层级按 h1 -> h2 -> h3 顺序嵌套，不要跳级。标题构成文档大纲，屏幕阅读器用户常通过标题快速导航。

错误：用标题标签控制字体大小、跳级（h1 后直接 h4）、多个 h1。

补充说明：

在实际落地正确使用 heading 层级时，建议结合 heading、h1-h6、语义化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

唯一 h1（30%）：每页一个 h1
顺序嵌套（40%）：不跳级
语义而非样式（30%）：用 CSS 控制大小

常见错误：

用 h1-h6 做字体大小调整
标题层级混乱，h1 后直接 h4
页面出现多个 h1 没有主标题

口头回答版：

heading 层级应唯一 h1、顺序嵌套不跳级，用于文档大纲而非样式控制。

FB-07-CO-B-015：什么是焦点顺序（focus order）？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：focus order、tabindex、键盘导航、可访问性 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 DOM 顺序与视觉顺序对焦点顺序的影响。

参考答案：

焦点顺序通常应与 DOM 顺序和视觉顺序一致，使用 Tab 键按预期移动。tabindex="0" 使元素可聚焦并纳入自然焦点顺序；tabindex="-1" 可通过脚本聚焦但不参与 Tab 顺序；正 tabindex 会打乱顺序，不推荐。

&lt;button tabindex="0"&gt;可聚焦&lt;/button&gt;
<div tabindex="-1" ref={el}>脚本聚焦</div>

评分维度：

DOM 与视觉（40%）：焦点顺序一致性
tabindex（40%）：0/-1/正值
避免正 tabindex（20%）：不打乱顺序

常见错误：

用正 tabindex 控制 Tab 顺序
CSS 改变视觉顺序后未调整 DOM 顺序
把 tabindex 加到所有 div 上

口头回答版：

焦点顺序应与 DOM 和视觉顺序一致，优先使用默认 Tab 顺序，必要时用 tabindex="0" 或 "-1"。

FB-07-CO-B-016：可访问性对 SEO 和用户体验有什么双重价值？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：07 可访问性标签：a11y、SEO、UX、语义化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明可访问性如何同时改善搜索引擎和真实用户体验。

参考答案：

可访问性强调语义化 HTML、alt 文本、标题结构和清晰导航，这些也是搜索引擎理解页面内容的重要依据。同时，键盘导航、充足对比度、清晰错误提示提升所有用户（包括临时受限用户）的体验。

因此，投入可访问性往往同时提升 SEO 和用户满意度。

补充说明：

在实际落地可访问性对 SEO 和用户体验有什么双重价值时，建议结合 a11y、SEO、UX 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

SEO（40%）：语义化、alt、标题
UX（40%）：键盘、对比度、错误提示
通用设计（20%）：惠及所有用户

常见错误：

认为可访问性只对残疾用户有价值
为了 SEO 堆砌关键词而破坏可访问性
忽略可访问性对移动端和老年用户的价值

口头回答版：

可访问性通过语义化、替代文本和清晰结构同时提升 SEO 和用户体验，惠及所有用户。

进阶题（18 道）

口头回答版：

在无效控件上设置 aria-invalid="true"，明确告诉辅助技术当前字段有误。 - 使用 aria-describedby 把错误信息与输入框关联，焦点进入输入时屏幕阅读器会朗读错误。 - 错误文本要具体说明出错原因和修正方法，而不是仅显示"输入错误"。 - 避免仅通过颜色（红色边框）传达错误，应同时提供图标或文字。

FB-07-CO-A-001：ARIA 是什么？何时应该使用 ARIA，何时应避免？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：ARIA、WAI-ARIA、roles、attributes、语义化 HTML 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 ARIA 的作用、角色（roles）与属性（attributes）的基本概念，并说明“能用原生 HTML 就不用 ARIA”的原因。

参考答案：

ARIA（Accessible Rich Internet Applications / WAI-ARIA） 是一套由 W3C 制定的规范，用于补充 HTML 语义，使复杂 Web 应用对辅助技术更可访问。

Roles：定义元素是什么，例如 role="dialog"、role="tablist"、role="alert"。
Properties / States：描述元素状态，例如 aria-expanded、aria-selected、aria-hidden、aria-disabled。

核心原则：

第一规则：能用原生 HTML 就不要用 ARIA。原生控件自带键盘、焦点、屏幕阅读器支持；ARIA 只改变语义，不改变行为。
不要给已有语义的元素添加冗余 role，例如 <button role="button"> 是多余的。
不要通过 ARIA 修复错误的 HTML。先修正结构和交互，再考虑 ARIA。
使用 ARIA 后，必须同时实现对应的键盘和焦点行为。

典型合理使用场景：自定义组合框、标签页、树形控件、可折叠面板等没有对应原生 HTML 的复杂组件。

评分维度：

解释 ARIA roles / attributes 的作用（30%）
说明“优先原生 HTML”原则（40%）
能举出合理与不合理使用 ARIA 的例子（30%）

常见错误：

认为 ARIA 能让任何元素自动键盘可用
给原生语义元素再加重复 role
用 role="presentation" 隐藏语义后又需要其交互

延伸追问：

ARIA 是否会影响 CSS 选择器或键盘事件？
aria-hidden="true" 有哪些常见陷阱？
如何检测页面上的 ARIA 使用是否合理？

相关题目：

FB-07-CO-B-001 什么是语义化 HTML
FB-07-CD-P-001 实现可访问的模态对话框

参考资源：

口头回答版：

ARIA（Accessible Rich Internet Applications / WAI-ARIA）是一套由 W3C 制定的规范，用于补充 HTML 语义，使复杂 Web 应用对辅助技术更可访问。 - Roles：定义元素是什么，例如 role="dialog"、role="tablist"、role="alert"。 - Properties / States：描述元素状态，例如 aria-expanded、aria-selected、aria-hidden、aria-disabled。

FB-07-CO-A-002：请解释 WCAG 的 A / AA / AAA 三个等级及其实际意义。

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：WCAG、合规、AA、AAA、法律法规 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 WCAG 2.1 / 2.2 的 A、AA、AAA 三个符合性等级，并解释企业在选择目标等级时应考虑哪些因素。

参考答案：

WCAG（Web Content Accessibility Guidelines）将可访问性要求分为三个等级：

A（基础）：最低门槛，解决最严重的可访问性障碍。例如提供文本替代、键盘可操作。
AA（推荐）：国际上最常见的合规目标，解决大部分用户的主要障碍。例如颜色对比度、焦点可见、表单标签。
AAA（最高）：最严格，通常仅适用于特定内容或局部功能。例如对比度 7:1、手语视频、扩展阅读级别。

等级关系：满足 AA 必须先满足 A；满足 AAA 必须先满足 AA（它们是包含关系）。

企业选择因素：

法律法规要求（如美国 ADA、欧洲 EAA、中国《无障碍环境建设法》）通常以 AA 为基准。
业务场景与用户群体（政府、金融、医疗往往要求更高）。
成本与收益平衡：AAA 对整站通常难以达成，可作为局部增强目标。

评分维度：

说清三个等级的含义与差异（40%）
说明等级之间的包含关系（20%）
结合业务 / 法律给出实际选择建议（40%）

常见错误：

认为 AA 是最高等级
忽略 AAA 通常只适用于局部内容
不清楚等级之间的包含关系

延伸追问：

哪些准则最难达到 AAA？
如何向产品经理解释把目标设为 AA 而不是 A？
你所在团队目前的合规目标是什么？如何验证？

参考资源：

口头回答版：

WCAG（Web Content Accessibility Guidelines）将可访问性要求分为三个等级： - A（基础）：最低门槛，解决最严重的可访问性障碍。例如提供文本替代、键盘可操作。 - AA（推荐）：国际上最常见的合规目标，解决大部分用户的主要障碍。

FB-07-CO-A-003：焦点指示器（focus indicator）有什么要求？如何自定义但不破坏可访问性？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：focus indicator、focus-visible、outline、键盘导航、焦点样式 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明焦点可见性的重要性，并给出 CSS 自定义焦点样式的最佳实践。

参考答案：

焦点指示器让用户知道当前键盘焦点在哪个元素上，是键盘可访问性的基础。

WCAG 2.2 的 Focus Appearance 对焦点区域提出了尺寸、对比度、相邻对比度等要求；即使不精确计算，也应保证焦点清晰可见。

最佳实践：

不要全局移除 outline：
css
```
/* 不推荐 */
* { outline: none; }
```
1
2

使用 :focus-visible 仅对键盘用户显示焦点：

css

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

保证焦点色与背景 / 元素有足够对比度，至少满足 3:1。
避免焦点样式与 hover 样式完全一致，否则用户难以辨认。

:focus 会在鼠标点击时也触发；:focus-visible 更智能，只在键盘 / 辅助输入需要时显示。

评分维度：

说明 WCAG 对 focus indicator 的基本要求（40%）
区分 :focus 与 :focus-visible（30%）
给出合理 CSS 实现（30%）

常见错误：

全局 outline: none 且不提供替代样式
焦点样式颜色太浅或与背景接近
鼠标点击的按钮也出现非常粗的 outline

延伸追问：

如何处理浏览器默认 outline 被设计系统覆盖的问题？
:focus-within 在什么场景下有用？
如果设计要求“无 outline”，你如何说服设计师？

参考资源：

口头回答版：

焦点指示器让用户知道当前键盘焦点在哪个元素上，是键盘可访问性的基础。 WCAG 2.2 的 Focus Appearance 对焦点区域提出了尺寸、对比度、相邻对比度等要求；即使不精确计算，也应保证焦点清晰可见。不要全局移除 outline：使用 :focus-visible 仅对键盘用户显示焦点：

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：skip link、键盘导航、Landmark、屏幕阅读器 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请解释 skip link 的作用，并说明实现时需要注意的关键点。

参考答案：

Skip link（跳转链接） 是页面顶部的一个隐藏链接，允许键盘和屏幕阅读器用户跳过重复的导航，直接跳到主内容区。

实现要点：

位置：放在 <body> 开头，通常是第一个可聚焦元素。
目标容器：链接指向主内容容器（如 <main id="main-content">）。

目标容器需要 tabindex="-1"，否则点击 skip link 后焦点不会移动到目标区域，屏幕阅读器也不会朗读新位置。

html

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

CSS：默认隐藏（如 position: absolute; left: -9999px），:focus 时显示在可视区域顶部。

不要把 skip link 设为 display: none 或 visibility: hidden，否则无法获得焦点。

评分维度：

说明 skip link 的作用与位置（30%）
解释目标容器为何需要 tabindex="-1"（40%）
给出 CSS 显示逻辑（30%）

常见错误：

目标容器没有 tabindex="-1"，焦点不移动
使用 display: none 隐藏 skip link
跳转到 <h1> 但不设置 tabindex="-1"

延伸追问：

如果页面有多个内容区（如主内容、侧边栏），是否需要多个 skip link？
在 SPA 路由切换后，skip link 的行为应如何处理？
移动端是否需要 skip link？

参考资源：

口头回答版：

Skip link（跳转链接）是页面顶部的一个隐藏链接，允许键盘和屏幕阅读器用户跳过重复的导航，直接跳到主内容区。位置：放在 <body> 开头，通常是第一个可聚焦元素。目标容器：链接指向主内容容器（如 <main id="main-content">）。目标容器需要 tabindex="-1"，否则点击 skip link 后焦点不会移动到目标区域，屏幕阅读器也不会朗读新位置。

题型：手写代码题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：custom select、ARIA、键盘、roving tabindex、菜单 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请用原生 HTML / CSS / JavaScript 实现一个可键盘操作、可被屏幕阅读器识别的自定义下拉菜单。要求写出关键 ARIA 属性与键盘事件处理。

参考答案：

核心 ARIA 与交互：

html

<button id="menu-button"
        aria-haspopup="true"
        aria-expanded="false"
        aria-controls="menu-list">
  操作
</button>
<ul id="menu-list"
    role="menu"
    tabindex="-1"
    aria-labelledby="menu-button"
    hidden>
  <li role="menuitem" tabindex="-1">复制</li>
  <li role="menuitem" tabindex="-1">粘贴</li>
  <li role="menuitem" tabindex="-1">删除</li>
</ul>

关键键盘交互：

Enter / Space / ↓：打开菜单，焦点移到第一个菜单项。
↑ / ↓：在菜单项之间移动（使用 aria-activedescendant 或 roving tabindex）。
Home / End：跳到第一个 / 最后一个菜单项。
Esc：关闭菜单，焦点返回按钮。
Tab：在菜单打开时通常应被限制在菜单内（焦点陷阱）。

const button = document.getElementById('menu-button');
const menu = document.getElementById('menu-list');
const items = Array.from(menu.querySelectorAll('[role="menuitem"]'));
let activeIndex = -1;

function open() {
  menu.hidden = false;
  button.setAttribute('aria-expanded', 'true');
  activeIndex = 0;
  items[activeIndex].focus(); // roving tabindex 方案
}

function close() {
  menu.hidden = true;
  button.setAttribute('aria-expanded', 'false');
  button.focus();
}

button.addEventListener('click', () => {
  menu.hidden ? open() : close();
});

menu.addEventListener('keydown', (e) => {
  if (e.key === 'ArrowDown') {
    activeIndex = (activeIndex + 1) % items.length;
    items[activeIndex].focus();
    e.preventDefault();
  } else if (e.key === 'ArrowUp') {
    activeIndex = (activeIndex - 1 + items.length) % items.length;
    items[activeIndex].focus();
    e.preventDefault();
  } else if (e.key === 'Escape') {
    close();
  }
});

也可使用 aria-activedescendant 方案：焦点保持在 role="menu" 上，通过该属性指示当前激活项。

评分维度：

正确使用 ARIA roles / states（role="menu"、aria-expanded、aria-haspopup 等）（30%）
实现方向键、Esc、Enter / Space 等键盘交互（40%）
焦点管理（打开进入菜单、关闭返回按钮）（30%）

常见错误：

只加 role="menu" 但不处理键盘事件
使用 aria-expanded 但忘记同步更新
焦点不进入菜单项，导致屏幕阅读器无法感知选项

延伸追问：

使用 aria-activedescendant 与真正移动 DOM 焦点各有什么优劣？
如何实现菜单项的 typeahead（首字母快速定位）？
多级菜单（menubar）如何处理方向键和焦点？

参考资源：

口头回答版：

核心 ARIA 与交互： - Enter / Space / ↓：打开菜单，焦点移到第一个菜单项。 - ↑ / ↓：在菜单项之间移动（使用 aria-activedescendant 或 roving tabindex）。 - Home / End：跳到第一个 / 最后一个菜单项。

FB-07-SC-A-001：设计一个带错误提示的可访问表单。

题型：场景设计题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：表单验证、error message、aria-invalid、aria-describedby、场景设计 出现频率：高频 预计回答时长：5-8 分钟

题目描述：假设你正在实现一个登录表单，需要在前端完成字段校验并在提交时给出错误提示。请从可访问性角度设计这个表单的交互与反馈机制。

参考答案：

每个字段有明确标签：

html

<label for="email">邮箱</label>
<input id="email" type="email" aria-required="true" />

实时 / 提交后错误关联：

错误发生时设置 aria-invalid="true"。

使用 aria-describedby 将输入框与错误信息关联。

html

<input id="email" aria-invalid="true" aria-describedby="email-error" />
<p id="email-error" class="error">请输入有效的邮箱地址</p>

提交时的焦点管理：
- 如果有错误，将焦点移动到页面顶部的错误汇总或第一个无效字段。
- 错误汇总使用 role="alert" 或 aria-live="polite"，让用户立即感知。
不单纯依赖颜色：
- 错误信息除了红色，还应包含图标和文本说明。
修复后清除状态：
- 用户修正后移除 aria-invalid，更新或清空 aria-describedby 指向的错误信息。

不要把错误信息只放在 title 或 placeholder 中，也不要依赖 toast 而不做字段级关联。

评分维度：

错误信息与输入框的正确关联（40%）
提交后的焦点 / 实时反馈策略（30%）
不依赖颜色传达错误状态（30%）

常见错误：

错误信息放在输入框下方但不与输入框关联
提交失败时没有任何焦点管理
对所有字段校验使用 alert() 打断用户

延伸追问：

实时校验（onBlur）与提交后校验在可访问性上各有什么利弊？
密码要求列表如何与输入框关联？
如果使用 React，如何利用 FormContext 统一管理 aria-invalid 和 aria-describedby？

相关题目：

FB-07-CO-B-003 如何为表单控件提供可访问的标签

参考资源：

口头回答版：

每个字段有明确标签：实时 / 提交后错误关联： - 错误发生时设置 aria-invalid="true"。 - 使用 aria-describedby 将输入框与错误信息关联。

FB-07-CA-A-001：分析下面自定义弹窗代码的可访问性问题。

题型：代码分析题难度：🟡 进阶 岗位层级：高级 面试知识域：07 可访问性标签：modal、dialog、focus trap、代码分析、键盘 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请指出以下自定义弹窗代码中的可访问性问题，并给出修改建议。

html

<div class="modal-overlay">
  <div class="modal">
    <h2>确认删除</h2>
    <p>删除后无法恢复，是否继续？</p>
    <button onclick="cancel()">取消</button>
    <button onclick="confirm()">确认</button>
    <span class="close" onclick="close()">×</span>
  </div>
</div>

参考答案：

问题与修复：

缺少 dialog 角色与 modal 状态

html

<div class="modal" role="dialog" aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">确认删除</h2>
  ...
</div>

关闭按钮不是可聚焦元素
- 应改为 <button>，并添加可访问名称。
没有焦点陷阱（focus trap）
- 打开弹窗时，焦点应限制在弹窗内；按 Tab 不应跑到弹窗背后的页面元素。
没有焦点恢复
- 关闭弹窗后，焦点应回到触发弹窗的元素。
不支持 Escape 关闭
- 弹窗通常应监听 Escape 键关闭。
背景内容未被隔离
- 应使用 inert 或 aria-hidden="true" 将弹窗外的内容从可访问树中临时移除。

评分维度：

识别 role / aria-modal / aria-labelledby 缺失（30%）
指出焦点陷阱与焦点恢复问题（40%）
指出键盘关闭与背景隔离问题（30%）

常见错误：

只关注视觉样式，忽略键盘和屏幕阅读器体验
给 <div> 加 role="dialog" 但不处理焦点管理
关闭弹窗后焦点丢失，导致屏幕阅读器用户不知道当前位置

延伸追问：

如何正确实现焦点陷阱？请说出至少两种方案。
inert 属性的 polyfill 与兼容性问题？
如果有多个嵌套弹窗，焦点栈应如何管理？

相关题目：

FB-07-CD-P-001 实现可访问的模态对话框

参考资源：

WAI - Dialog Modal Pattern

口头回答版：

缺少 dialog 角色与 modal 状态关闭按钮不是可聚焦元素 - 应改为 <button>，并添加可访问名称。没有焦点陷阱（focus trap）

FB-07-CO-A-005：ARIA 中 role、state、property 有什么区别？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：07 可访问性标签：ARIA、role、state、property、可访问性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 ARIA 中 role、state、property 三类属性的区别，并举例说明。

参考答案：

role（角色）：定义元素是什么，如 role="button"、`role="navigation"。role 通常静态不变，决定辅助技术如何向用户播报。
state（状态）：描述元素的当前状态，会随交互变化，如 aria-expanded、aria-checked、aria-selected、aria-disabled。
property（属性）：描述元素的固有特征或关系，通常不随交互变化，如 aria-label、aria-describedby、aria-controls、aria-owns。

使用原则：

优先使用原生语义标签，再补充 ARIA。
使用 role 后，必须提供对应的键盘和交互行为。
state 必须及时更新，否则辅助技术会播报错误状态。

评分维度：

role 的概念与示例（40%）
state 与 property 的区分（40%）
使用原则（20%）

常见错误：

把 aria-label 当成 state。
给 <div> 加 role="button" 但不处理键盘事件。

延伸追问：

自定义标签页（Tabs）需要哪些 role 和 state？
aria-pressed 和 aria-checked 有什么区别？

相关题目：

FB-07-CO-A-001 ARIA 是什么
FB-07-CO-P-002 屏幕阅读器浏览网页

参考资源：

ARIA Roles, States, and Properties

口头回答版：

role（角色）：定义元素是什么，如 role="button"、role="navigation"。 role 通常静态不变，决定辅助技术如何向用户播报。 - state（状态）：描述元素的当前状态，会随交互变化，如 aria-expanded、aria-checked、aria-selected、aria-disabled。 - property（属性）：描述元素的固有特征或关系，通常不随交互变化，如 aria-label、aria-describedby、aria-controls、aria-owns`。

FB-07-CO-A-009：如何为数据表格提供无障碍支持？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：表格、th、scope、可访问性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 table、caption、th、scope 和 thead/tbody 的使用。

参考答案：

使用 table 元素，为列/行标题使用 th 并添加 scope="col"/scope="row"。为表格添加 caption 描述内容。复杂表格使用 headers 属性关联单元格与多行/列标题。避免用 div 模拟表格导致屏幕阅读器无法解析行列关系。

补充说明：

在实际落地为数据表格提供无障碍支持时，建议结合表格、th、scope 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

th（30%）：表头单元格
scope（30%）：col/row
caption（20%）：表格标题
headers（20%）：复杂表格关联

常见错误：

用 div + CSS 模拟表格
th 不写 scope 导致屏幕阅读器方向不清
复杂表头没有使用 headers 关联

口头回答版：

数据表格应使用 table、th、scope、caption，复杂表头使用 headers 关联，避免 div 模拟。

FB-07-CO-A-010：aria-describedby 与 aria-labelledby 有什么区别？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：ARIA、aria-describedby、aria-labelledby、标签 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明两个属性的用途和优先级差异。

参考答案：

aria-labelledby 指向元素名称/标签，功能等同于 HTML label，优先级高于原生标签。aria-describedby 指向补充描述信息，不会替代名称，只作为额外说明。

&lt;input aria-labelledby="name-label" aria-describedby="name-hint" /&gt;
<div id="name-label">用户名</div>
<div id="name-hint">3-20 个字符</div>

评分维度：

aria-labelledby（40%）：名称/标签
aria-describedby（40%）：补充描述
优先级（20%）：labelledby 高于原生标签

常见错误：

把描述信息放在 aria-labelledby 中导致名称冗长
aria-describedby 指向可见元素但该元素没有文本
用 aria-label 和 aria-labelledby 重复定义名称

口头回答版：

aria-labelledby 提供元素名称，aria-describedby 提供补充描述，两者功能不同。

FB-07-CO-A-011：如何为视频/音频内容提供无障碍替代方案？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：视频、音频、字幕、可访问性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明字幕、转录文本、音频描述和手语视频的作用。

参考答案：

视频应提供同步字幕（closed captions）给听障用户，提供音频描述给视障用户。音频内容应提供完整文字转录。重要视觉信息不应只通过视频传达。

&lt;video controls&gt;
  &lt;track src="captions.vtt" kind="captions" srclang="zh" label="中文字幕"&gt;
&lt;/video&gt;

评分维度：

字幕（30%）：captions
转录（30%）：文本稿
音频描述（30%）：描述视觉信息
track（10%）：VTT 文件

常见错误：

自动生成的字幕不校对
只提供一种语言字幕
关键信息只出现在视频中无文字说明

口头回答版：

视频应提供字幕、音频描述和转录文本，音频提供文字稿，使用 track 元素加载 VTT。

FB-07-CO-A-012：什么是键盘陷阱（keyboard trap）？如何避免？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：键盘陷阱、focus trap、键盘导航、可访问性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明键盘陷阱的表现和 Modal 等组件中的正确做法。

参考答案：

键盘陷阱指焦点无法通过 Tab 键离开某个区域。正确做法：在 Modal 中焦点循环限制在弹窗内，但可通过 Esc 或关闭按钮退出。焦点离开弹窗后应回到触发元素。

// 弹窗关闭后恢复焦点

trigger.focus();

补充说明：

在实际落地键盘陷阱（keyboard trap）如何避免时，建议结合键盘陷阱、focus trap、键盘导航的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

表现（30%）：Tab 无法离开
焦点循环（40%）：限制在弹窗内
恢复焦点（30%）：关闭后回到触发元素

常见错误：

Modal 打开后焦点仍可在页面任意元素移动
弹窗内 Tab 焦点丢失
关闭弹窗后未恢复焦点导致用户迷失

口头回答版：

键盘陷阱指 Tab 无法离开某区域；Modal 应限制焦点循环并提供退出方式，关闭后恢复焦点。

FB-07-CO-A-013：如何为动态加载内容使用 aria-live？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：aria-live、动态内容、实时区域、屏幕阅读器 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 aria-live 的 polite/assertive/off 取值及使用场景。

参考答案：

aria-live 让屏幕阅读器在内容变化时朗读更新。polite 等当前朗读完成后再播报；assertive 立即打断；off 不播报。

<div aria-live="polite" aria-atomic="true">
  {statusMessage}
</div>

用于加载完成提示、表单错误、通知消息等。

评分维度：

取值（40%）：polite/assertive/off
aria-atomic（30%）：整体播报
场景（30%）：状态提示、错误、通知

常见错误：

所有动态内容都用 assertive 打断用户
aria-live 区域初始为空，更新后仍不播报
在频繁变化的区域使用 aria-live 导致刷屏

口头回答版：

aria-live 用于动态内容播报，polite 等待当前朗读结束，assertive 立即打断，assertive 应谨慎使用。

FB-07-CO-A-014：可见焦点指示器（focus indicator）的要求是什么？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：focus indicator、可见焦点、键盘、WCAG 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 WCAG 对焦点可见性的要求及自定义样式注意事项。

参考答案：

WCAG 要求键盘焦点必须可见，焦点指示器应有足够的尺寸和对比度。自定义 focus 样式时不应完全移除 outline，可改用 box-shadow 或 border，但要确保可见。

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

评分维度：

可见性（40%）：焦点必须可见
对比度（30%）：与背景对比足够
实现（30%）：outline 或替代方案

常见错误：

全局设置 outline: none 且不替代
焦点样式与背景色对比度不足
鼠标点击时也显示突兀的焦点样式

口头回答版：

焦点指示器必须可见且对比度足够，可用 :focus-visible 和 outline/box-shadow 实现，不要完全移除 outline。

FB-07-CO-A-015：如何为图标按钮提供可访问名称？

题型：概念题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：图标按钮、aria-label、可访问名称、按钮 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请给出至少两种为无文本图标按钮添加名称的方法。

参考答案：

使用 aria-label 描述按钮功能。2) 使用 visually hidden 文本供屏幕阅读器读取。3) 使用 title 属性（仅鼠标悬浮提示，不建议作为主要可访问名称）。
<button aria-label="搜索"> <svg aria-hidden="true">...</svg> </button> <button> <svg aria-hidden="true">...</svg> 搜索 </button>

评分维度：

aria-label（40%）：按钮功能描述
visually hidden（40%）：隐藏文本
aria-hidden（20%）：图标隐藏

常见错误：

图标按钮没有可访问名称
用 title 替代 aria-label 作为主要名称
svg 没有 aria-hidden 导致屏幕阅读器重复读取

口头回答版：

图标按钮应通过 aria-label 或隐藏文本提供可访问名称，图标本身应 aria-hidden。

FB-07-SC-A-002：设计一个无障碍文件上传组件

题型：场景设计题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：文件上传、a11y、表单、错误提示 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明上传组件的可访问性要点，包括按钮、进度、错误和删除。

参考答案：

使用 label 关联隐藏 input[type=file]，自定义按钮可通过 label 触发。2) 上传进度通过 aria-live 播报。3) 文件名、大小、删除按钮使用语义化元素并关联 aria-describedby。4) 错误信息明确说明格式/大小限制。5) 支持键盘操作和拖拽回退。

补充说明：

在实际落地设计一个无障碍文件上传组件时，建议结合文件上传、a11y、表单的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

隐藏 input（30%）：label 关联
进度播报（30%）：aria-live
错误与删除（30%）：语义与关联
键盘（10%）：Tab/Enter/Space

常见错误：

自定义按钮未与 file input 关联导致无法触发
进度变化未播报
错误信息只显示图标颜色

口头回答版：

无障碍文件上传需 label 关联 input、aria-live 播报进度、明确错误信息、支持键盘操作。

FB-07-SC-A-003：设计一个可访问的日期选择器

题型：场景设计题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：日期选择器、DatePicker、键盘、ARIA 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明日期选择器的键盘导航、焦点管理和 ARIA 属性。

参考答案：

输入框支持手动输入并关联格式提示。2) 弹层面板使用 role="dialog"，日期网格 role="grid"，日期单元格 role="gridcell"。3) 方向键移动日期，Enter/Space 选择，Esc 关闭。4) 选中日期设置 aria-selected，当前日期 aria-current="date"。5) 焦点在打开时进入面板，关闭后返回输入框。

补充说明：

在实际落地设计一个可访问的日期选择器时，建议结合日期选择器、DatePicker、键盘的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

键盘（30%）：方向键/Enter/Esc
角色（30%）：dialog/grid/gridcell
状态（20%）：aria-selected/current
焦点（20%）：打开/关闭焦点管理

常见错误：

日期网格使用 table 但没有 ARIA 角色
方向键移动导致页面滚动
未提供手动输入回退

口头回答版：

可访问日期选择器需 dialog/grid 角色、方向键导航、aria-selected/current 状态，以及良好的焦点管理。

FB-07-SS-A-001：如何在团队中推广无障碍测试？

题型：软技能题难度：🟡 进阶 岗位层级：初级 / 高级 面试知识域：07 可访问性标签：无障碍测试、团队、流程、a11y 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明推广无障碍测试的策略和工具。

参考答案：

策略：1) 建立可访问性检查清单；2) 将 a11y 纳入代码评审；3) 引入自动化工具（axe-core、Lighthouse、eslint-plugin-jsx-a11y）；4) 提供屏幕阅读器使用培训；5) 设置 CI 门禁和定期人工审计。

从小范围试点，展示 ROI 和用户反馈，逐步扩大。

评分维度：

自动化（30%）：axe/Lighthouse/eslint
流程（30%）：CR、CI、审计
培训（20%）：屏幕阅读器使用
试点（20%）：小范围验证

常见错误：

只依赖自动化工具忽略键盘和屏幕阅读器测试
一次性要求所有代码达到 AAA
没有度量指标导致改进缺乏方向

口头回答版：

推广无障碍测试需自动化工具、流程嵌入、培训和试点，逐步建立团队文化。

深入题（13 道）

口头回答版：

role（角色）：定义元素是什么，如 role="button"、role="navigation"。 role 通常静态不变，决定辅助技术如何向用户播报。 - state（状态）：描述元素的当前状态，会随交互变化，如 aria-expanded、aria-checked、aria-selected、aria-disabled。 - property（属性）：描述元素的固有特征或关系，通常不随交互变化，如 aria-label、aria-describedby、aria-controls、aria-owns`。

FB-07-CO-P-001：浏览器如何构建可访问性树（accessibility tree）？它与 DOM 树的关系是什么？

题型：概念题难度：🔴 深入 岗位层级：专家 面试知识域：07 可访问性、03 浏览器原理标签：accessibility tree、DOM、浏览器、屏幕阅读器、platform APIs 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释 accessibility tree 的生成过程、包含的信息，以及它与 DOM 树、渲染树的关系。

参考答案：

浏览器在解析 HTML / CSS 并构建 DOM 和渲染树的同时，会生成一棵 accessibility tree（可访问性树），用于向屏幕阅读器、语音识别工具等辅助技术（AT）暴露页面信息。

生成过程：

浏览器基于 DOM 节点和计算样式，决定哪些节点需要暴露给辅助技术。
过滤掉不可见节点（如 display: none、visibility: hidden、aria-hidden="true" 的节点）。
将语义信息（原生标签、ARIA role / state / property）映射为平台无障碍 API 对象。

每个可访问对象通常包含：

Role：元素角色（如 button、link、heading）。
Name：可访问名称（来自 label、alt、aria-label 等）。
State / Property：状态与属性（如 checked、expanded、selected）。
Value：值（如 input 的当前值）。
Description：补充描述（如 aria-describedby）。

平台 API：

Windows：MSAA / UI Automation / IAccessible2
macOS：NSAccessibility（AX API）
Linux：AT-SPI
iOS / Android：UIAccessibility / AccessibilityNodeInfo

Accessibility tree 不是 DOM 的完整复制：它是语义层抽象，且会受 CSS 影响。

评分维度：

解释 accessibility tree 的生成机制（40%）
说明它与 DOM / 渲染树的关系（30%）
说明平台无障碍 API 的作用（30%）

常见错误：

认为 accessibility tree 就是 DOM 树
不知道 CSS 也会影响 accessibility tree
混淆 aria-hidden="true" 与 display: none 的语义差异

延伸追问：

display: contents 对可访问性树有什么影响？
visibility: hidden 与 opacity: 0 在 accessibility tree 中的区别？
如何用浏览器 DevTools 查看 accessibility tree？

参考资源：

口头回答版：

浏览器在解析 HTML / CSS 并构建 DOM 和渲染树的同时，会生成一棵 accessibility tree（可访问性树），用于向屏幕阅读器、语音识别工具等辅助技术（AT）暴露页面信息。

FB-07-CO-P-002：屏幕阅读器是如何浏览网页的？虚拟光标与焦点模式有什么区别？

题型：概念题难度：🔴 深入 岗位层级：专家 面试知识域：07 可访问性标签：屏幕阅读器、NVDA、JAWS、VoiceOver、虚拟光标 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请简述屏幕阅读器的工作原理，并解释“虚拟光标 / 浏览模式”与“焦点模式 / 表单模式”的区别。

参考答案：

工作原理：

屏幕阅读器通过操作系统提供的 平台无障碍 API 读取浏览器暴露的 accessibility tree。
它将 role、name、state、value 等信息转换为语音、盲文或屏幕放大提示。
用户通过键盘快捷键（如 heading 跳转、landmark 跳转、链接列表）快速定位内容。

两种主要模式：

模式	名称	行为
浏览模式（Browse Mode / 虚拟光标）	阅读静态内容	方向键按文档语义顺序移动，快捷键跳转 heading / landmark / 链接
焦点模式（Focus Mode / 表单模式）	与控件交互	按键直接传给控件（如在文本框输入、在 select 中使用方向键）

切换方式：

当焦点进入表单控件或具有 role="application" 的区域时，屏幕阅读器通常自动切换到焦点模式。
离开控件后返回浏览模式。

前端实现影响：正确使用 ARIA roles 和原生语义，能让屏幕阅读器自动切换模式；错误使用 role="application" 会剥夺用户的浏览模式快捷键。

评分维度：

说明屏幕阅读器读取 accessibility tree 的基本原理（30%）
区分浏览模式与焦点模式（40%）
说明前端实现如何影响模式切换（30%）

常见错误：

认为屏幕阅读器只是“把文字读出来”
混淆 aria-live 与虚拟光标阅读
滥用 role="application"，导致整个页面无法使用浏览模式

延伸追问：

为什么 role="application" 要慎用？
如何测试键盘操作与屏幕阅读器朗读是否一致？
NVDA、JAWS、VoiceOver、TalkBack 在模式切换上有什么差异？

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-CO-P-003：什么是 ARIA 实时区域（live region）？如何使用 `aria-live`、`aria-atomic`、`aria-relevant`？

题型：概念题难度：🔴 深入 岗位层级：专家 面试知识域：07 可访问性标签：live region、aria-live、aria-atomic、aria-relevant、动态内容 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 live region 的用途，并说明 aria-live、aria-atomic、aria-relevant 三个属性的含义与使用场景。

参考答案：

Live region（实时区域） 用于在页面内容动态变化时通知屏幕阅读器，而无需将焦点移动到变化的内容上。典型场景：Toast 提示、加载状态、表单错误汇总、聊天消息。

属性说明：

aria-live：定义通知优先级。
- off：不主动通知（默认）。
- polite：当前朗读完成后通知，适合大多数非紧急信息。
- assertive：立即打断当前朗读，仅用于真正紧急的信息（如严重错误、安全警告）。
aria-atomic：
- false（默认）：只朗读变化的部分。
- true：变化时朗读整个 live region 的内容。
aria-relevant：控制哪些变化会被通知。
- additions（默认）：新增节点时通知。
- removals：节点移除时通知。
- text：文本变化时通知。
- all：以上全部。

最佳实践：

预先在 DOM 中创建空的 live region 容器，动态向其追加内容。
避免频繁更新，防止屏幕阅读器“刷屏”。
不要把重要操作按钮放在 live region 内。

html

<div id="status" aria-live="polite" aria-atomic="true"></div>
<script>
  document.getElementById('status').textContent = '保存成功';
</script>

评分维度：

说明 live region 的用途（30%）
正确解释三个属性的含义（50%）
给出最佳实践示例（20%）

常见错误：

每次需要提示时都创建新的 live region
对普通反馈使用 aria-live="assertive"
忽略 aria-atomic，导致只朗读变化片段而语义不完整

延伸追问：

在 React / Vue 中如何安全使用 live region？
多个 live region 同时更新时，屏幕阅读器如何处理？
倒计时 / 进度条应使用 live region 还是 role="status" / role="alert"？

相关题目：

FB-07-SC-A-001 设计一个带错误提示的可访问表单

参考资源：

口头回答版：

Live region（实时区域）用于在页面内容动态变化时通知屏幕阅读器，而无需将焦点移动到变化的内容上。典型场景：Toast 提示、加载状态、表单错误汇总、聊天消息。

题型：手写代码题难度：🔴 深入 岗位层级：专家 面试知识域：07 可访问性标签：dialog、modal、focus trap、inert、键盘、焦点恢复 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请用原生 HTML / JavaScript（或框架思路）手写一个符合可访问性要求的模态框，要求支持键盘操作、焦点管理和屏幕阅读器。

参考答案：

推荐方案：使用原生 <dialog> 元素

html

<dialog id="confirm-dialog" aria-labelledby="dialog-title" aria-describedby="dialog-desc">
  <h2 id="dialog-title">确认删除</h2>
  <p id="dialog-desc">删除后无法恢复。</p>
  <button id="cancel-btn">取消</button>
  <button id="confirm-btn">确认删除</button>
</dialog>

const dialog = document.getElementById('confirm-dialog');
const openBtn = document.getElementById('open-btn');
const cancelBtn = document.getElementById('cancel-btn');
let previousActiveElement;

openBtn.addEventListener('click', () => {
  previousActiveElement = document.activeElement;
  dialog.showModal(); // 自动焦点陷阱 + 背景置灰 + ESC 关闭
});

dialog.addEventListener('close', () => {
  previousActiveElement?.focus(); // 焦点恢复
});

cancelBtn.addEventListener('click', () => dialog.close());

<dialog>.showModal() 已经内置：

焦点陷阱（Tab 在 dialog 内循环）
::backdrop 样式
Escape 键关闭
顶层显示（top layer）

自定义实现要点（当无法使用 <dialog> 时）：

role="dialog"、aria-modal="true"、aria-labelledby。
打开时记录 document.activeElement，关闭后恢复焦点。
使用 inert 或 aria-hidden="true" 隔离背景。
实现焦点陷阱（监听 Tab / Shift+Tab）。
监听 Escape 关闭。
焦点首次落在对话框本身或第一个可聚焦元素上。

评分维度：

HTML / ARIA 使用正确（30%）
焦点陷阱与焦点恢复实现（40%）
键盘关闭、背景隔离、焦点初始位置（30%）

常见错误：

使用 <div> 模拟 dialog 但不加任何 role
不 trap focus，导致 Tab 跑到弹窗背后
关闭后焦点丢失或不回到触发元素
背景仍可交互

延伸追问：

多层模态对话框如何管理焦点栈？
<dialog> 与自定义实现各有什么优劣？
模态框内包含 iframe 时，焦点陷阱如何处理？

参考资源：

口头回答版：

推荐方案：使用原生 <dialog> 元素 <dialog>.showModal() 已经内置： - 焦点陷阱（Tab 在 dialog 内循环） - ::backdrop 样式

FB-07-SC-P-001：如何为一个复杂的自定义组件（如 Autocomplete）设计无障碍方案？

题型：场景设计题难度：🔴 深入 岗位层级：专家 面试知识域：07 可访问性标签：autocomplete、combobox、ARIA、键盘、场景设计 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请设计一个支持键盘和屏幕阅读器的 Autocomplete（自动补全）组件，说明应遵循的 ARIA 模式、键盘交互与动态反馈策略。

参考答案：

推荐遵循 ARIA Combobox Pattern。

结构示例：

html

<label for="city-input">城市</label>
<input id="city-input"
       type="text"
       role="combobox"
       aria-expanded="false"
       aria-controls="city-list"
       aria-activedescendant=""
       aria-autocomplete="list" />
<ul id="city-list" role="listbox" aria-label="城市建议">
  <li id="opt-1" role="option" aria-selected="false">北京</li>
  <li id="opt-2" role="option" aria-selected="false">上海</li>
</ul>

键盘交互：

↓ / Alt+↓ / 输入时：打开列表框并高亮第一项。
↑ / ↓：在选项间移动高亮。
Enter：选中当前高亮项。
Esc：关闭列表框。
Home / End：移动光标到输入框文本首尾。
支持输入首字母快速定位（typeahead）。

屏幕阅读器反馈：

使用 aria-activedescendant 让屏幕阅读器朗读当前高亮项。
使用 live region 播报结果数量变化，例如“找到 5 个结果”。
加载中状态使用 aria-busy="true" 或 live region 提示。

焦点管理：

焦点始终保持在输入框上，通过 aria-activedescendant 指示虚拟选中项。
选中后关闭列表框，焦点仍在输入框，可选中结果文本或保持不动。

评分维度：

正确选择 ARIA Combobox Pattern（40%）
键盘交互完整（30%）
屏幕阅读器反馈策略（30%）

常见错误：

使用 role="select" 等不存在的 role
忽略 aria-activedescendant，导致屏幕阅读器不朗读当前项
列表异步加载时没有加载状态反馈

延伸追问：

多选 Autocomplete 应如何扩展 ARIA 模式？
异步结果返回较慢时，live region 如何设计？
移动端软键盘与 Autocomplete 的 focus 行为如何协调？

参考资源：

口头回答版：

推荐遵循 ARIA Combobox Pattern。

FB-07-PE-P-001：无障碍性对页面性能有什么影响？如何优化？

题型：性能优化题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：07 可访问性、27 性能工程标签：性能、accessibility tree、渲染、大列表、懒加载 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请讨论 Web 可访问性实现可能带来的性能开销，并给出优化策略。

参考答案：

性能影响：

Accessibility tree 规模：DOM 越大，浏览器需要维护的可访问性树越大，辅助技术遍历成本越高。
频繁的 ARIA 状态更新：大量 aria-live / aria-busy / aria-expanded 变化会触发辅助技术重新朗读或重新构建视图。
多余的 DOM 节点：滥用 aria-hidden、空容器、包装元素会增加树深度。
Live region 刷屏：高频更新 live region 会导致屏幕阅读器卡顿或重复朗读。
计算样式与重排：focus indicator、动画、动态 inert 切换可能影响渲染。

优化策略：

保持 DOM 精简：优先使用语义化 HTML，减少不必要的包装 div。
虚拟滚动 + 可访问性：对长列表使用虚拟滚动时，保留适当的 aria-setsize、aria-posinset 或 live region 提示总条数。
合并 live region 更新：防抖或批量更新提示信息，避免刷屏。
避免频繁切换 aria-hidden：一次性设置父级 inert，而非逐个节点修改。
延迟加载非关键辅助内容：如复杂的图表描述、详细错误说明可懒加载。
测量工具：Lighthouse、axe、浏览器 Performance / Accessibility 面板。

评分维度：

分析可访问性对性能的影响因素（40%）
能说明测量方法（20%）
给出具体优化方案（40%）

常见错误：

认为可访问性不会影响性能
为了“可访问性”盲目添加大量 ARIA 标记
虚拟滚动后不做任何屏幕阅读器补偿

延伸追问：

虚拟滚动列表对屏幕阅读器有哪些影响？如何补偿？
大量实时数据更新时，如何减少 live region 开销？
content-visibility 对 accessibility tree 有影响吗？

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-CO-P-004：常用的无障碍测试工具有哪些？如何建立测试流程？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：07 可访问性标签：无障碍测试、a11y、axe、Lighthouse、屏幕阅读器 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请列举常用的无障碍测试工具，并说明如何在项目中建立可访问性测试流程。

参考答案：

常用工具：

自动化扫描：axe-core、Lighthouse、eslint-plugin-jsx-a11y、WAVE。
手动测试：键盘遍历（Tab/Shift+Tab/Enter/Escape）、屏幕阅读器（NVDA、JAWS、VoiceOver、TalkBack）。
视觉检查：颜色对比度工具（如 Colour Contrast Analyser）、缩放测试（200% 放大）。

测试流程：

开发阶段：IDE/编辑器插件实时提示，PR 中运行 axe-core + 单元测试。
构建阶段：CI 中跑 Lighthouse 和 a11y 扫描，阻断严重问题。
验收阶段：手动走查关键路径，邀请真实视障用户或专业审核。
线上阶段：持续监控，收集用户反馈，定期复测。

评分维度：

工具覆盖（40%）：自动与手动工具
手动测试方法（30%）：键盘、屏幕阅读器
流程集成（30%）：CI、验收、线上

常见错误：

只依赖 Lighthouse 分数，忽略手动测试。
测试只在项目上线前做一次。

延伸追问：

axe-core 和 Lighthouse 的无障碍评分有什么区别？
如何测试动态加载内容的可访问性？

相关题目：

FB-07-CP-R-001 无障碍测试集成 CI/CD
FB-07-PE-P-001 无障碍性能优化

参考资源：

口头回答版：

自动化扫描：axe-core、Lighthouse、eslint-plugin-jsx-a11y、WAVE。 - 手动测试：键盘遍历（Tab/Shift+Tab/Enter/Escape）、屏幕阅读器（NVDA、JAWS、VoiceOver、TalkBack）。 - 视觉检查：颜色对比度工具（如 Colour Contrast Analyser）、缩放测试（200% 放大）。开发阶段：IDE/编辑器插件实时提示，PR 中运行 axe-core + 单元测试。

FB-07-CO-P-005：如何实现一个可访问的 Tabs 组件？

题型：概念题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：Tabs、ARIA、键盘、可访问组件 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Tabs 的 role、状态、键盘交互和焦点管理。

参考答案：

结构：tablist 包含 tab，每个 tab 对应 tabpanel。选中 tab 设置 aria-selected="true"，未选中为 false。tabpanel 通过 aria-labelledby 关联 tab。

键盘：左右箭头切换 tab，Home/End 到第一个/最后一个 tab，Tab 键进入激活的面板内容。激活方式可为自动激活或手动激活（空格/回车）。

评分维度：

角色（30%）：tablist/tab/tabpanel
状态（30%）：aria-selected
键盘（30%）：方向键/Home/End
激活方式（10%）：自动/手动

常见错误：

用 div 模拟 tab 但未添加 role 和状态
Tab 键在 tab 间切换而不是箭头键
tabpanel 没有与 tab 关联

口头回答版：

可访问 Tabs 需设置 tablist/tab/tabpanel 角色、aria-selected、aria-labelledby，并用方向键切换。

FB-07-CO-P-006：如何实现一个可访问的 Accordion 组件？

题型：概念题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：Accordion、ARIA、展开收起、可访问组件 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Accordion 的按钮、面板状态、键盘和屏幕阅读器支持。

参考答案：

标题按钮使用 button，aria-expanded 表示展开状态，aria-controls 关联面板 id。面板使用 aria-labelledby 关联按钮。允许多个面板同时展开或限制仅一个展开。

键盘：Enter/Space 切换当前按钮；若限制单个展开，方向键可在标题间移动。

评分维度：

按钮（30%）：使用 button 元素
状态（30%）：aria-expanded/aria-controls
面板关联（30%）：aria-labelledby
键盘（10%）：Enter/Space 切换

常见错误：

用 div 做标题并监听 click
展开状态没有通过 aria-expanded 通知屏幕阅读器
面板未与按钮关联导致上下文丢失

口头回答版：

可访问 Accordion 使用 button 做标题，aria-expanded 表示状态，aria-controls/aria-labelledby 关联面板。

FB-07-CO-P-007：复杂表单验证的无障碍反馈如何设计？

题型：概念题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：表单验证、ARIA、错误提示、可访问性 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明错误提示与表单控件的关联、焦点管理和 live region 的使用。

参考答案：

错误信息通过 aria-describedby 与输入框关联。2) 提交时将焦点移到第一个错误字段。3) 使用 aria-invalid="true" 标记无效字段。4) 对全局错误摘要使用 aria-live="polite"。5) 错误信息应具体说明如何修复。
<input aria-describedby="email-error" aria-invalid="true" />
请输入有效的邮箱地址

评分维度：

关联（30%）：aria-describedby
焦点（30%）：首个错误字段聚焦
状态（20%）：aria-invalid
摘要（20%）：aria-live

常见错误：

错误提示仅用颜色标识
提交后未将焦点移到错误字段
aria-describedby 指向错误提示但该提示动态未更新

口头回答版：

复杂表单验证需用 aria-describedby 关联错误、aria-invalid 标记、焦点移到首个错误、live region 播报摘要。

FB-07-CO-P-008：屏幕阅读器中的地标（landmark）与跳转有什么关系？

题型：概念题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：landmark、main、nav、屏幕阅读器 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 HTML5 语义元素如何映射为 ARIA landmark 及其实际作用。

参考答案：

HTML5 元素 main、nav、aside、header、footer、section[aria-labelledby] 映射为 ARIA landmark。屏幕阅读器用户可通过快捷键在 landmark 之间跳转，快速定位页面区域。

正确使用 landmark 能显著提升页面导航效率。

评分维度：

映射（40%）：HTML5 到 ARIA landmark
跳转（30%）：屏幕阅读器快捷键
设计（30%）：合理划分区域

常见错误：

所有内容包在 div 中无 landmark
页面出现多个 main
用 section 不加 aria-label 导致 landmark 列表都是无标签 section

口头回答版：

HTML5 语义元素映射为 ARIA landmark，屏幕阅读器用户可快速跳转，应合理划分页面区域。

FB-07-CO-P-009：如何为图表（Chart）添加无障碍文本？

题型：概念题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：图表、数据可视化、ARIA、可访问性 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明图表的替代文本、数据表格和交互键盘支持。

参考答案：

提供图表总结文本，描述主要趋势和关键数据。2) 使用 aria-label 或 figure/figcaption 描述图表。3) 提供可访问的替代数据表格。4) 为图表元素添加键盘焦点和 aria-roledescription。
<figure> <figcaption>2024 年各季度销售额，Q4 最高为 120 万</figcaption> <canvas role="img" aria-label="2024 年季度销售柱状图"></canvas> </figure>

评分维度：

替代文本（40%）：总结趋势和关键数据
数据表格（30%）：提供表格化数据
交互（30%）：键盘焦点与 role

常见错误：

图表没有替代文本
把原始数据直接作为 aria-label 导致冗长
图表交互无法通过键盘访问

口头回答版：

图表应提供总结文本、数据表格替代和键盘交互，帮助屏幕阅读器用户理解数据。

FB-07-SS-P-001：无障碍合规审计流程与整改闭环如何建立？

题型：软技能题难度：🔴 深入 岗位层级：高级 / 专家 面试知识域：07 可访问性标签：无障碍审计、WCAG、合规、整改 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请描述从审计计划到整改验证的完整流程。

参考答案：

流程：1) 确定范围与 WCAG 目标等级（AA/AAA）。2) 自动化扫描（axe/Lighthouse）。3) 人工审计：键盘导航、屏幕阅读器、颜色对比度。4) 产出缺陷清单，按严重等级排序。5) 分配修复责任人并设定期限。6) 修复后复测，更新测试用例。7) 持续监控与回归。

评分维度：

范围与等级（20%）：目标等级
自动化（20%）：工具扫描
人工审计（20%）：键盘/读屏/对比度
闭环（40%）：修复、复测、回归

常见错误：

只做自动化扫描
没有按严重等级排序修复
修复后不复测导致问题反复

口头回答版：

无障碍审计应包含自动化扫描、人工测试、缺陷修复、复测和持续监控的完整闭环。

架构题（16 道）

口头回答版：

自动化扫描：axe-core、Lighthouse、eslint-plugin-jsx-a11y、WAVE。 - 手动测试：键盘遍历（Tab/Shift+Tab/Enter/Escape）、屏幕阅读器（NVDA、JAWS、VoiceOver、TalkBack）。 - 视觉检查：颜色对比度工具（如 Colour Contrast Analyser）、缩放测试（200% 放大）。开发阶段：IDE/编辑器插件实时提示，PR 中运行 axe-core + 单元测试。

FB-07-SD-R-001：如何为大型企业级前端制定可访问性治理策略？

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性标签：a11y 治理、WCAG、合规、设计系统、CI/CD 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一套覆盖设计、开发、测试、发布流程的企业级前端可访问性治理体系，并说明关键角色、工具和考核指标。

参考答案：

治理框架：

明确目标与政策
- 以 WCAG 2.1 / 2.2 AA 为最低目标；关键业务线可局部 AAA。
- 制定《可访问性设计规范》和《开发 Checklist》。
角色与职责
- 可访问性负责人（A11y Lead / Champion）
- 设计师：颜色、对比度、焦点、响应式
- 前端工程师：语义 HTML、ARIA、键盘、组件实现
- QA：自动化 + 手动测试
- 产品经理：将可访问性纳入需求与 DoD
设计与研发阶段
- 设计系统提供带 a11y 规范的组件、focus tokens、颜色板。
- Code Review 必须检查标签、焦点、ARIA 使用。
- 静态检查：eslint-plugin-jsx-a11y、Stylelint 对比度、Axe Linter。
测试阶段
- 自动化：Lighthouse、axe-core、Playwright + axe。
- 手动：键盘走查、屏幕阅读器（NVDA / VoiceOver）测试。
- 用户测试：邀请残障用户参与可用性测试。
CI/CD 与发布
- PR 阶段运行 a11y 检查，阻断严重 / 关键级别问题。
- 生成可访问性报告，建立基线与趋势。
持续监控与改进
- 线上监控：错误率、用户反馈、合规审计。
- 培训与文化建设：定期分享、比赛、纳入绩效考核。

考核指标：

自动化检测得分 / 严重问题数
手动测试通过率
可访问性 bug 平均修复时长
组件库 a11y 覆盖率

评分维度：

治理框架完整性（40%）
工具链与 CI/CD 集成（30%）
流程、角色与文化机制（30%）

常见错误：

只谈工具，忽视培训和流程
没有明确的合规目标与指标
把可访问性完全交给 QA，研发不参与

延伸追问：

如何向业务方证明可访问性投入的价值？
VPAT / ACR（Accessibility Conformance Report）是什么？何时需要？
如何在不拖慢迭代速度的前提下推进治理？

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-SD-R-002：如何设计一个可访问的组件库 / 设计系统？

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性、14 设计体系与组件库标签：Design System、component library、ARIA patterns、tokens、可访问组件 出现频率：中频 预计回答时长：15-20 分钟

题目描述：从架构角度说明，如何确保组件库输出的组件在默认情况下就是可访问的，同时兼顾易用性与可定制性。

参考答案：

组件模型：

基于 WAI-ARIA Authoring Practices
- 每个复杂组件（Dialog、Tabs、Combobox、Tree）都遵循官方 ARIA Pattern。
封装键盘与焦点逻辑
- 将 focus trap、roving tabindex、focus-visible、Escape 处理等封装为 hooks / utils，组件开发者无需重复实现。
标签与描述自动关联
- 组件内部自动生成唯一 id，自动将 label / error / description 与控件通过 aria-labelledby、aria-describedby 关联。
- 同时保留用户自定义 aria-label / aria-labelledby 的入口。
样式与语义解耦
- 使用 design tokens 管理颜色对比度、焦点样式、间距。
- 提供高对比度 / 大字号主题支持。
文档与示例
- Storybook 中展示每个组件的键盘操作、ARIA 属性、禁忌用法。
- 提供可访问性 API 文档（如 Modal 的 initialFocusRef、returnFocus）。
自动化测试
- 每个组件配套 axe-core 测试、键盘交互测试、屏幕阅读器测试用例。

示例设计原则：

默认使用原生语义元素，再暴露 low-level primitives 给高级场景。
禁止为了视觉完全覆盖焦点样式；提供可覆盖但必须满足对比度的 token。

评分维度：

组件模型与 ARIA 模式集成（40%）
样式 / 焦点 / 对比度 token 设计（30%）
测试、文档与开发者体验（30%）

常见错误：

组件只关注视觉还原，忽略键盘与焦点
把 ARIA 属性全部交给业务方配置，组件不默认处理
没有为组件写可访问性测试

延伸追问：

如果消费者覆盖了组件样式导致焦点不可见，组件库如何防御？
主题切换时如何动态保证颜色对比度？
组件 API 中是否应该暴露 role 让用户自定义？

相关题目：

FB-07-CP-R-001 将无障碍测试集成到 CI/CD

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-CP-R-001：如何将无障碍测试集成到前端工程化与 CI/CD 中？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性、13 代码质量与测试、12 CI/CD 标签：a11y testing、CI/CD、axe-core、Lighthouse、自动化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一套前端可访问性测试策略，覆盖本地开发、代码审查、集成测试到持续集成流水线，并说明各类测试的局限性与互补关系。

参考答案：

分层测试策略：

静态分析（最早介入）
- eslint-plugin-jsx-a11y / eslint-plugin-vue-a11y
- Axe Linter、Accessibility Insights for Web
- Stylelint 检查颜色对比度 token
单元 / 组件测试
- React：React Testing Library + jest-axe
- Vue：Vitest + @vue/test-utils + axe-core
- 断言：无严重可访问性违规、正确 label 关联
集成测试
- 键盘交互测试（Tab 顺序、Enter / Space、Escape）
- 焦点管理测试（打开弹窗、关闭后焦点恢复）
E2E 测试
- Playwright / Cypress + axe-core
- 覆盖关键用户路径（登录、下单、搜索）
手动与辅助技术测试
- 键盘走查
- 屏幕阅读器（NVDA / JAWS / VoiceOver / TalkBack）
- 颜色滤镜 / 色盲模拟

CI/CD 集成：

PR 阶段运行静态分析与组件 / E2E a11y 测试。
设置严重（critical）和关键（serious）级别错误为阻断项。
生成 PR 可访问性报告（diff report），仅对新增问题告警。
建立基线（baseline），允许逐步修复历史问题。

局限性：

自动化只能覆盖约 30% 的 WCAG 问题；颜色对比度、屏幕阅读器体验、认知可访问性需要人工判断。
工具可能误报或漏报（如自定义组件的键盘行为）。

评分维度：

测试分层设计合理（40%）
工具选型与集成方式（30%）
CI 门禁策略与局限性说明（30%）

常见错误：

认为自动化测试可以覆盖全部可访问性问题
没有阈值策略，导致流水线频繁失败
只在上线前跑一次 Lighthouse

延伸追问：

如何处理 axe-core 的误报？
如何对 PR 生成可访问性差异报告？
视觉回归测试能否发现焦点样式回归？如何补充？

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-SD-R-003：面向全球用户的产品的国际化（i18n）与无障碍如何协同设计？

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性、33 国际化标签：i18n、RTL、本地化、屏幕阅读器、语言标记 出现频率：低频 预计回答时长：10-15 分钟

题目描述：请讨论多语言、RTL（从右到左）排版、本地化内容对可访问性的影响，并给出协同设计方案。

参考答案：

关键协同点：

语言标记
- 根据当前语言动态设置 <html lang="zh-CN"> / <html lang="ar">。
- 屏幕阅读器依赖 lang 属性切换发音规则。
方向与布局
- 使用逻辑属性（inline-start、margin-inline-start）而非固定 left / right。
- 根据语言设置 dir="rtl"，并同步翻转焦点指示器、图标方向（如返回箭头）。
文本扩展与缩放
- 德语、荷兰语通常比英语长 30% 以上；中文排版需更大行高。
- 支持浏览器文本缩放（up to 200%）而不丢失内容或功能。
屏幕阅读器体验
- 日期、数字、货币应根据 locale 格式化。
- 避免在图片中嵌入文字；若必须，提供本地化 alt text。
- Live region 内容应随语言切换重新播报当前语言。
文化与认知可访问性
- 颜色含义因文化不同（如红色在中国代表喜庆，在西方常代表错误）。
- 不仅依赖颜色，要配合图标 + 文本。
工程化
- i18n key 与 a11y label 统一管理，避免缺失翻译导致屏幕阅读器读 key。
- RTL 与 a11y 自动化测试纳入 CI。

评分维度：

lang / dir 处理（30%）
文本扩展、布局与焦点样式适配（30%）
屏幕阅读器与文化适配（40%）

常见错误：

页面语言写死为 lang="en"
使用 CSS transform 或绝对定位简单“镜像”RTL
忽略屏幕阅读器对数字 / 日期的本地化朗读

延伸追问：

如何测试 RTL 下的键盘焦点顺序？
复数、性别、敬语对屏幕阅读器朗读有什么影响？
如果某些语言没有对应的屏幕阅读器语音包，如何降级？

参考资源：

口头回答版：

可以结合自己的项目经验，分点说明核心概念、关键流程和注意事项。

FB-07-CP-R-002：如果线上出现无障碍合规诉讼或用户投诉，你会如何处理与修复？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性标签：合规、事件响应、修复流程、用户投诉、VPAT 出现频率：低频 预计回答时长：10-15 分钟

题目描述：作为前端架构师，假设团队收到一起关于页面不可用的用户投诉或合规审计反馈，请描述从接到反馈到修复上线的完整处理流程。

参考答案：

接收与分类
- 记录用户信息、辅助技术、浏览器、操作步骤、受影响页面。
- 评估严重程度和涉及的 WCAG 准则。
复现
- 使用相同或类似的辅助技术（屏幕阅读器、键盘）复现问题。
- 必要时与投诉用户进一步沟通确认。
影响评估
- 判断是单点问题还是系统性问题。
- 评估法律风险、业务影响和受影响用户规模。
修复方案
- 短期：能否通过 ARIA、标签、焦点等低风险改动快速缓解？
- 长期：是否需要重构组件、更新设计系统、补充自动化测试？
验证
- 自动化测试（axe、键盘测试）+ 手动屏幕阅读器验证。
- 邀请真实用户或内部 a11y 专家复核。
上线与沟通
- 修复后通知用户 / 客服 / 法务。
- 更新 VPAT / ACR（如需要）。
复盘与预防
- 将问题抽象为组件 / Checklist 改进项。
- 补充测试用例，开展团队培训。

评分维度：

处理流程完整性（40%）
技术修复思路与优先级判断（30%）
沟通、合规与预防机制（30%）

常见错误：

未充分复现就急着改代码
修复后不与用户沟通确认
只修单点，不做回归和系统性预防

延伸追问：

如何防止同类问题复发？
与法务、产品、客服团队协作时需要注意什么？
如果修复需要较大重构但业务排期紧张，你如何决策？

参考资源：

口头回答版：

记录用户信息、辅助技术、浏览器、操作步骤、受影响页面。 - 评估严重程度和涉及的 WCAG 准则。 - 使用相同或类似的辅助技术（屏幕阅读器、键盘）复现问题。 - 必要时与投诉用户进一步沟通确认。

FB-07-SS-R-001：如何推动团队建立无障碍文化并获得资源支持？

题型：软技能题难度：⚫ 架构 岗位层级：架构师 面试知识域：07 可访问性、38 团队领导力标签：无障碍文化、团队协作、说服、培训、领导力 出现频率：低频 预计回答时长：10-15 分钟

题目描述：面对业务压力大、团队可访问性意识薄弱的情况，作为技术负责人，你会如何推动团队建立无障碍文化并争取到资源支持？

参考答案：

建立业务案例（Business Case）
- 法律与合规风险（ADA、EAA、国内法规）。
- 市场与用户规模（全球约有 10 亿+ 残障人士）。
- SEO、品牌声誉、易用性提升。
从小处入手，快速见效
- 先在 CI 中加入 eslint-plugin-jsx-a11y、Lighthouse 门禁。
- 修复一批高影响、低成本的 a11y 问题（如 alt、label、focus）。
嵌入开发流程
- 将可访问性纳入 Definition of Done（DoD）。
- Code Review 中增加 a11y Checklist。
培养内部倡导者（Champions）
- 每个业务线指定 a11y champion，负责答疑和推动。
培训与感知
- 组织屏幕阅读器体验日、邀请残障用户分享。
- 提供系统培训（ARIA、键盘、测试工具）。
指标与激励
- 设定可量化的目标（如严重 a11y bug 数下降 50%）。
- 将可访问性纳入团队 / 个人 OKR。
争取高层支持
- 用数据和案例向 CTO / VP 汇报，争取专人或专项预算。

关键：避免指责和道德绑架，强调“更好的产品”和“更低的风险”。

评分维度：

推动策略的可行性（40%）
沟通与说服技巧（30%）
建立可持续机制的能力（30%）

常见错误：

只强调“做正确的事”而缺乏数据支撑
一次性推行过多规则导致团队抵触
没有建立反馈和激励机制

延伸追问：

如果设计师或产品经理强烈反对修改视觉设计以满足对比度，你怎么沟通？
如何衡量“无障碍文化”是否真正建立？
在跨团队（如后端、Native）中如何协同推进？

参考资源：

口头回答版：

建立业务案例（Business Case） - 法律与合规风险（ADA、EAA、国内法规）。 - 市场与用户规模（全球约有 10 亿+ 残障人士）。 - SEO、品牌声誉、易用性提升。

FB-07-CP-R-004：如何度量前端产品的可访问性成熟度？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：07 可访问性标签：可访问性成熟度、KPI、WCAG、自动化、用户反馈 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请设计一套可访问性成熟度度量体系，用于评估前端产品并驱动持续改进。

参考答案：

核心指标：

合规率：页面/组件达到 WCAG 2.1 AA 的比例，按 A/AA/AAA 分层统计。
缺陷密度：自动扫描发现的无障碍问题数，按严重级别（critical/serious/moderate/minor）分类。
覆盖率：纳入无障碍测试的关键页面比例、手动审计覆盖率。
用户反馈：残障用户投诉数、工单闭环率、可用性测试发现的问题数。
组织能力：团队培训覆盖率、无障碍负责人配备、设计/开发规范落地率。

落地方式：

建立可访问性看板，定期同步给技术委员会。
把核心指标纳入团队 OKR 或质量门禁。
每季度做一次成熟度评估，识别短板并制定改进计划。

评分维度：

指标体系完整性（40%）
数据收集与自动化（30%）
持续改进机制（30%）

常见错误：

只看 Lighthouse 分数，忽略真实用户体验。
指标过多导致无法聚焦。

延伸追问：

如何向管理层证明无障碍投入的价值？
合规率和用户满意度出现冲突时如何权衡？

相关题目：

FB-07-SD-R-001 可访问性治理策略
FB-07-SS-R-001 推动无障碍文化

参考资源：

口头回答版：

合规率：页面/组件达到 WCAG 2.1 AA 的比例，按 A/AA/AAA 分层统计。 - 缺陷密度：自动扫描发现的无障碍问题数，按严重级别（critical/serious/moderate/minor）分类。 - 覆盖率：纳入无障碍测试的关键页面比例、手动审计覆盖率。 - 用户反馈：残障用户投诉数、工单闭环率、可用性测试发现的问题数。

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：07 可访问性（a11y）标签：屏幕阅读器、WCAG、ARIA、键盘、可访问性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是 Web 无障碍（a11y）？为什么要关注它。

参考答案：

Web 无障碍是指让网站和应用能够被尽可能多的人使用，包括视觉、听觉、运动、认知障碍者，以及临时性障碍用户。

关注原因：

法律合规：国内外法规要求数字产品达到一定可访问性标准。
商业收益：扩大用户群体，提升 SEO 和用户体验。
社会责任：体现包容性设计价值。
技术质量：无障碍代码通常语义化更好、可维护性更高。

评分维度：

定义准确（40%）
列举至少 3 个关注原因（40%）
举例说明（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

Web 无障碍是指让网站和应用能够被尽可能多的人使用，包括视觉、听觉、运动、认知障碍者，以及临时性障碍用户。关注原因： - 法律合规：国内外法规要求数字产品达到一定可访问性标准。 - 商业收益：扩大用户群体，提升 SEO 和用户体验。 - 社会责任：体现包容性设计价值。

FB-07-CO-B-009：解释 WCAG 的 POUR 四项原则。

题目描述：解释 WCAG 的 POUR 四项原则。。

参考答案：

原则	含义
Perceivable（可感知）	用户能感知信息和界面
Operable（可操作）	用户能操作界面
Understandable（可理解）	内容和操作可理解
Robust（健壮）	内容可被各种辅助技术解析

每项原则下都有具体成功标准，按 A/AA/AAA 三级划分。

评分维度：

完整解释四项原则（60%）
说明 conformance 等级（25%）
举例说明（15%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

| 原则 | 含义 | |------|------| | Perceivable（可感知） | 用户能感知信息和界面 | | Operable（可操作） | 用户能操作界面 | | Understandable（可理解） | 内容和操作可理解 | | Robust（健壮） | 内容可被各种辅助技术解析 | 每项原则下都有具体成功标准，按 A/AA/AAA 三级划分。

FB-07-CO-B-010：语义化 HTML 对无障碍有什么作用？

题目描述：语义化 HTML 对无障碍有什么作用。

参考答案：

语义化 HTML 的作用：

为屏幕阅读器提供结构信息（标题、地标、列表、表格）。
让键盘导航更自然（<button>、<a> 默认可聚焦）。
提供默认交互行为（表单提交、链接跳转）。
改善 SEO 和可维护性。

例如：

<nav> 让屏幕阅读器用户快速找到导航。
<main> 帮助跳转到主要内容。
<button> 自带键盘激活行为。

评分维度：

说出语义化对辅助技术的作用（40%）
说明键盘和默认行为收益（30%）
举例说明（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

语义化 HTML 的作用： - 为屏幕阅读器提供结构信息（标题、地标、列表、表格）。 - 让键盘导航更自然（<button56>、<a65> 默认可聚焦）。 - 提供默认交互行为（表单提交、链接跳转）。 - 改善 SEO 和可维护性。

FB-07-CO-B-011：图片的 alt 属性应该如何填写？

题目描述：图片的 alt 属性应该如何填写。

参考答案：

图片类型	alt 写法
信息性图片	简洁描述图片内容
功能性图片	描述功能而非外观
装饰性图片	`alt=""`
复杂图表	简要概述 + 详细描述放在附近

示例：

alt="2024 年 Q1 销售额同比增长 25%"
alt=""（装饰性）
避免 alt="图片" 这类无意义描述。

评分维度：

区分图片类型（40%）
给出正确示例（40%）
说明常见错误（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

| 图片类型 | alt 写法 | |---------|---------| | 信息性图片 | 简洁描述图片内容 | | 功能性图片 | 描述功能而非外观 | | 装饰性图片 | alt="" | | 复杂图表 | 简要概述 + 详细描述放在附近 | 示例： - alt="2024 年 Q1 销售额同比增长 25%" - alt=""（装饰性） - 避免 alt="图片" 这类无意义描述。

FB-07-CO-B-012：为什么不应该只用颜色传达信息？

题目描述：为什么不应该只用颜色传达信息。

参考答案：

色盲、低视力或在强光环境下的用户可能无法区分颜色。如果仅用颜色表示状态，这些用户会丢失关键信息。

正确做法：

配合图标、文字、形状。
使用纹理或图案区分。
确保信息有多个感知通道。

示例：

错误：<span class="red">失败</span>
正确：<span class="error">✕ 失败</span>

评分维度：

说明问题（40%）
给出解决方案（40%）
举例说明（20%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

色盲、低视力或在强光环境下的用户可能无法区分颜色。如果仅用颜色表示状态，这些用户会丢失关键信息。正确做法： - 配合图标、文字、形状。 - 使用纹理或图案区分。

FB-07-CO-A-006：什么是 ARIA？应该在什么情况下使用？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：07 可访问性（a11y）标签：屏幕阅读器、WCAG、ARIA、键盘、可访问性 出现频率：中频 预计回答时长：5-8 分钟

题目描述：什么是 ARIA？应该在什么情况下使用。

参考答案：

ARIA（Accessible Rich Internet Applications）是一组属性，用于补充 HTML 无法表达的语义信息，包括角色（role）、状态（state）和属性（property）。

使用原则：

优先使用原生 HTML：能用 <button> 就不用 role="button"。
需要时使用 ARIA：自定义组件（标签页、对话框、下拉菜单）需要补充语义。
确保状态同步：ARIA 属性必须随组件状态实时更新。
提供可访问名称：每个交互元素都应有名称。

评分维度：

解释 ARIA 组成（40%）
说明使用原则（40%）
举例说明（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

ARIA（Accessible Rich Internet Applications）是一组属性，用于补充 HTML 无法表达的语义信息，包括角色（role）、状态（state）和属性（property）。使用原则： 1. 优先使用原生 HTML：能用 <button130> 就不用 role="button"。 2. 需要时使用 ARIA：自定义组件（标签页、对话框、下拉菜单）需要补充语义。 3. 确保状态同步：ARIA 属性必须随组件状态实时更新。

FB-07-SD-A-001：如何设计一个可访问的模态对话框？

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：07 可访问性（a11y）标签：屏幕阅读器、WCAG、ARIA、键盘、可访问性 出现频率：中频 预计回答时长：5-8 分钟

题目描述：如何设计一个可访问的模态对话框。

参考答案：

语义结构：使用 <dialog> 或 role="dialog"、aria-modal="true"。
标题关联：使用 aria-labelledby 关联标题。
焦点管理：
- 打开时焦点移到对话框内第一个可聚焦元素或标题。
- Tab 在对话框内循环（焦点陷阱）。
- 关闭时焦点返回触发按钮。
关闭方式：支持 Esc 键和明确的关闭按钮。
背景处理：建议禁用背景交互（非必须，但提升体验）。

补充说明：

在实际落地设计一个可访问的模态对话框时，建议结合屏幕阅读器、WCAG、ARIA 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

语义结构（20%）
焦点管理（40%）
关闭与恢复（25%）
代码示例（15%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

语义结构：使用 <dialog13> 或 role="dialog"、aria-modal="true"。 2. 标题关联：使用 aria-labelledby 关联标题。 3. 焦点管理： - 打开时焦点移到对话框内第一个可聚焦元素或标题。 - Tab 在对话框内循环（焦点陷阱）。

FB-07-CO-A-007：表单可访问性有哪些关键点？

题目描述：表单可访问性有哪些关键点。

参考答案：

标签关联：每个输入框都有 <label>，使用 for 或隐式关联。
错误提示：使用 aria-invalid、aria-describedby 关联错误信息。
必填标识：使用 required 和视觉/辅助技术提示。
分组：使用 <fieldset> 和 <legend> 对单选/多选分组。
实时验证：使用 aria-live 播报动态错误。

评分维度：

标签关联（30%）
错误提示（30%）
分组与必填（25%）
实时验证（15%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

标签关联：每个输入框都有 <label18>，使用 for 或隐式关联。 2. 错误提示：使用 aria-invalid、aria-describedby 关联错误信息。 3. 必填标识：使用 required 和视觉/辅助技术提示。 4. 分组：使用 <fieldset130> 和 <legend143> 对单选/多选分组。

FB-07-CO-A-008：如何进行可访问性测试？

题目描述：如何进行可访问性测试。

参考答案：

自动化测试：

axe DevTools、Lighthouse、Pa11y
Storybook a11y addon
ESLint 插件（jsx-a11y、vue-a11y）

手动测试：

键盘-only 操作全站。
使用屏幕阅读器（NVDA、JAWS、VoiceOver）。
高对比度模式、页面放大 200%。
色盲模拟器。

用户测试：

邀请真实障碍用户参与测试。

评分维度：

自动化工具（30%）
手动测试方法（40%）
用户测试价值（20%）
测试融入流程（10%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

自动化测试： - axe DevTools、Lighthouse、Pa11y - Storybook a11y addon - ESLint 插件（jsx-a11y、vue-a11y）手动测试： - 键盘-only 操作全站。 - 使用屏幕阅读器（NVDA、JAWS、VoiceOver）。 - 高对比度模式、页面放大 200%。用户测试： - 邀请真实障碍用户参与测试。

可访问性（a11y）面试题 ​

目录 ​

基础题（12 道） ​

FB-07-CO-B-001：什么是语义化 HTML？它对可访问性有什么价值？ ​

FB-07-CO-B-002：图片的 alt 属性应该怎么写？哪些情况可以留空？ ​

FB-07-CO-B-003：如何为表单控件提供可访问的标签？ ​

FB-07-CO-B-004：键盘导航的基础原则是什么？tabindex 如何使用？ ​

FB-07-CO-B-005：颜色对比度对可访问性有什么要求？如何检测？ ​

FB-07-CA-B-001：下面这段代码存在哪些可访问性问题？ ​

FB-07-CO-B-006：为什么 placeholder 不能替代 label？ ​

FB-07-CO-B-007：如何为表单错误提示提供无障碍支持？ ​

FB-07-CO-B-013：WCAG 的 POUR 四项原则是什么？ ​

FB-07-CO-B-014：如何正确使用 heading 层级？ ​

FB-07-CO-B-015：什么是焦点顺序（focus order）？ ​

FB-07-CO-B-016：可访问性对 SEO 和用户体验有什么双重价值？ ​

进阶题（18 道） ​

FB-07-CO-A-001：ARIA 是什么？何时应该使用 ARIA，何时应避免？ ​

FB-07-CO-A-002：请解释 WCAG 的 A / AA / AAA 三个等级及其实际意义。 ​

FB-07-CO-A-003：焦点指示器（focus indicator）有什么要求？如何自定义但不破坏可访问性？ ​

FB-07-CO-A-004：什么是跳转链接（skip link）？如何实现？ ​

FB-07-CD-A-001：手写一个可访问的自定义下拉菜单（Button Menu）。 ​

FB-07-SC-A-001：设计一个带错误提示的可访问表单。 ​

FB-07-CA-A-001：分析下面自定义弹窗代码的可访问性问题。 ​

FB-07-CO-A-005：ARIA 中 role、state、property 有什么区别？ ​

FB-07-CO-A-009：如何为数据表格提供无障碍支持？ ​

FB-07-CO-A-010：aria-describedby 与 aria-labelledby 有什么区别？ ​

FB-07-CO-A-011：如何为视频/音频内容提供无障碍替代方案？ ​

FB-07-CO-A-012：什么是键盘陷阱（keyboard trap）？如何避免？ ​

FB-07-CO-A-013：如何为动态加载内容使用 aria-live？ ​

FB-07-CO-A-014：可见焦点指示器（focus indicator）的要求是什么？ ​

FB-07-CO-A-015：如何为图标按钮提供可访问名称？ ​

FB-07-SC-A-002：设计一个无障碍文件上传组件 ​

FB-07-SC-A-003：设计一个可访问的日期选择器 ​

FB-07-SS-A-001：如何在团队中推广无障碍测试？ ​

深入题（13 道） ​

FB-07-CO-P-001：浏览器如何构建可访问性树（accessibility tree）？它与 DOM 树的关系是什么？ ​

FB-07-CO-P-002：屏幕阅读器是如何浏览网页的？虚拟光标与焦点模式有什么区别？ ​

FB-07-CO-P-003：什么是 ARIA 实时区域（live region）？如何使用 aria-live、aria-atomic、aria-relevant？ ​

FB-07-CD-P-001：实现一个可访问的模态对话框（Modal Dialog）。 ​

FB-07-SC-P-001：如何为一个复杂的自定义组件（如 Autocomplete）设计无障碍方案？ ​

FB-07-PE-P-001：无障碍性对页面性能有什么影响？如何优化？ ​

FB-07-CO-P-004：常用的无障碍测试工具有哪些？如何建立测试流程？ ​

FB-07-CO-P-005：如何实现一个可访问的 Tabs 组件？ ​

FB-07-CO-P-006：如何实现一个可访问的 Accordion 组件？ ​

FB-07-CO-P-007：复杂表单验证的无障碍反馈如何设计？ ​

FB-07-CO-P-008：屏幕阅读器中的地标（landmark）与跳转有什么关系？ ​

FB-07-CO-P-009：如何为图表（Chart）添加无障碍文本？ ​

FB-07-SS-P-001：无障碍合规审计流程与整改闭环如何建立？ ​

架构题（16 道） ​

FB-07-SD-R-001：如何为大型企业级前端制定可访问性治理策略？ ​

FB-07-SD-R-002：如何设计一个可访问的组件库 / 设计系统？ ​

FB-07-CP-R-001：如何将无障碍测试集成到前端工程化与 CI/CD 中？ ​

FB-07-SD-R-003：面向全球用户的产品的国际化（i18n）与无障碍如何协同设计？ ​

FB-07-CP-R-002：如果线上出现无障碍合规诉讼或用户投诉，你会如何处理与修复？ ​

FB-07-SS-R-001：如何推动团队建立无障碍文化并获得资源支持？ ​

FB-07-CP-R-004：如何度量前端产品的可访问性成熟度？ ​

FB-07-CO-B-008：什么是 Web 无障碍（a11y）？为什么要关注它？ ​

FB-07-CO-B-009：解释 WCAG 的 POUR 四项原则。 ​

FB-07-CO-B-010：语义化 HTML 对无障碍有什么作用？ ​

FB-07-CO-B-011：图片的 alt 属性应该如何填写？ ​

FB-07-CO-B-012：为什么不应该只用颜色传达信息？ ​

二、进阶题 ​

FB-07-CO-A-006：什么是 ARIA？应该在什么情况下使用？ ​

FB-07-SD-A-001：如何设计一个可访问的模态对话框？ ​

FB-07-CO-A-007：表单可访问性有哪些关键点？ ​

FB-07-CO-A-008：如何进行可访问性测试？ ​

三、高级题 ​

目录

基础题（12 道）

FB-07-CO-B-001：什么是语义化 HTML？它对可访问性有什么价值？

FB-07-CO-B-002：图片的 `alt` 属性应该怎么写？哪些情况可以留空？

FB-07-CO-B-003：如何为表单控件提供可访问的标签？

FB-07-CO-B-004：键盘导航的基础原则是什么？`tabindex` 如何使用？

FB-07-CO-B-005：颜色对比度对可访问性有什么要求？如何检测？

FB-07-CA-B-001：下面这段代码存在哪些可访问性问题？

FB-07-CO-B-006：为什么 `placeholder` 不能替代 `label`？

FB-07-CO-B-007：如何为表单错误提示提供无障碍支持？

FB-07-CO-B-013：WCAG 的 POUR 四项原则是什么？

FB-07-CO-B-014：如何正确使用 heading 层级？

FB-07-CO-B-015：什么是焦点顺序（focus order）？

FB-07-CO-B-016：可访问性对 SEO 和用户体验有什么双重价值？

进阶题（18 道）

FB-07-CO-A-001：ARIA 是什么？何时应该使用 ARIA，何时应避免？

FB-07-CO-A-002：请解释 WCAG 的 A / AA / AAA 三个等级及其实际意义。

FB-07-CO-A-003：焦点指示器（focus indicator）有什么要求？如何自定义但不破坏可访问性？

FB-07-CO-A-004：什么是跳转链接（skip link）？如何实现？

FB-07-CD-A-001：手写一个可访问的自定义下拉菜单（Button Menu）。

FB-07-SC-A-001：设计一个带错误提示的可访问表单。

FB-07-CA-A-001：分析下面自定义弹窗代码的可访问性问题。

FB-07-CO-A-005：ARIA 中 role、state、property 有什么区别？

FB-07-CO-A-009：如何为数据表格提供无障碍支持？

FB-07-CO-A-010：aria-describedby 与 aria-labelledby 有什么区别？

FB-07-CO-A-011：如何为视频/音频内容提供无障碍替代方案？

FB-07-CO-A-012：什么是键盘陷阱（keyboard trap）？如何避免？

FB-07-CO-A-013：如何为动态加载内容使用 aria-live？

FB-07-CO-A-014：可见焦点指示器（focus indicator）的要求是什么？

FB-07-CO-A-015：如何为图标按钮提供可访问名称？

FB-07-SC-A-002：设计一个无障碍文件上传组件

FB-07-SC-A-003：设计一个可访问的日期选择器

FB-07-SS-A-001：如何在团队中推广无障碍测试？

深入题（13 道）

FB-07-CO-P-001：浏览器如何构建可访问性树（accessibility tree）？它与 DOM 树的关系是什么？

FB-07-CO-P-002：屏幕阅读器是如何浏览网页的？虚拟光标与焦点模式有什么区别？

FB-07-CO-P-003：什么是 ARIA 实时区域（live region）？如何使用 `aria-live`、`aria-atomic`、`aria-relevant`？

FB-07-CD-P-001：实现一个可访问的模态对话框（Modal Dialog）。

FB-07-SC-P-001：如何为一个复杂的自定义组件（如 Autocomplete）设计无障碍方案？

FB-07-PE-P-001：无障碍性对页面性能有什么影响？如何优化？

FB-07-CO-P-004：常用的无障碍测试工具有哪些？如何建立测试流程？

FB-07-CO-P-005：如何实现一个可访问的 Tabs 组件？

FB-07-CO-P-006：如何实现一个可访问的 Accordion 组件？

FB-07-CO-P-007：复杂表单验证的无障碍反馈如何设计？

FB-07-CO-P-008：屏幕阅读器中的地标（landmark）与跳转有什么关系？

FB-07-CO-P-009：如何为图表（Chart）添加无障碍文本？

FB-07-SS-P-001：无障碍合规审计流程与整改闭环如何建立？

架构题（16 道）

FB-07-SD-R-001：如何为大型企业级前端制定可访问性治理策略？

FB-07-SD-R-002：如何设计一个可访问的组件库 / 设计系统？

FB-07-CP-R-001：如何将无障碍测试集成到前端工程化与 CI/CD 中？

FB-07-SD-R-003：面向全球用户的产品的国际化（i18n）与无障碍如何协同设计？

FB-07-CP-R-002：如果线上出现无障碍合规诉讼或用户投诉，你会如何处理与修复？

FB-07-SS-R-001：如何推动团队建立无障碍文化并获得资源支持？

FB-07-CP-R-004：如何度量前端产品的可访问性成熟度？

FB-07-CO-B-008：什么是 Web 无障碍（a11y）？为什么要关注它？

FB-07-CO-B-009：解释 WCAG 的 POUR 四项原则。

FB-07-CO-B-010：语义化 HTML 对无障碍有什么作用？

FB-07-CO-B-011：图片的 alt 属性应该如何填写？

FB-07-CO-B-012：为什么不应该只用颜色传达信息？

二、进阶题

FB-07-CO-A-006：什么是 ARIA？应该在什么情况下使用？

FB-07-SD-A-001：如何设计一个可访问的模态对话框？

FB-07-CO-A-007：表单可访问性有哪些关键点？

FB-07-CO-A-008：如何进行可访问性测试？

三、高级题