视觉认知无障碍

• font-size-adjust 的作用
• 可变字体（variable font）
• 弱视用户阅读优化

font-size-adjust 可调整字体在小字号下的 x-height（x 字高），使不同字体在相同字号下视觉高度一致，提升可读性——对弱视用户尤其重要，因为小字号下 x-height 小的字体更难读。OpenType 可变字体（variable font）通过单个字体文件包含多个轴（weight、width、optical size 等），可精细化调节字重、光学尺寸等，为不同阅读场景（如大字号正文、小字号 UI）提供更优字形，且可控体积。工程价值：结合 font-size-adjust 与可变字体的 optical size/weight 轴，可为弱视用户提供更清晰、可调的阅读体验，支持字体缩放与增强。现代字体栈可用 font-optical-sizing: auto 与可变字体轴微调。

弱视用户需要更清晰的字体。font-size-adjust 保证同比可读高度，可变字体提供精细字形控制，二者都是"字体层面提升可读性"的工程手段，配合文本缩放与 WCAG 重缩放要求。

• 各偏好媒体查询的含义
• 无障碍适配
• 工程价值

prefers-color-scheme（浅/深色）、prefers-contrast（对比度增强）、prefers-reduced-transparency（减少半透明）、prefers-reduced-data（减少数据/媒体，如限制高流量内容）等媒体查询，让应用响应用户感知与设备偏好。无障碍工程价值：深色模式需保证对比度与可读性；prefers-contrast 增强对比度利弱视/低对比度用户；reduced-transparency 减少毛玻璃/半透明，利文字可读性；reduced-data 减少大媒体/重内容，利低带宽用户。工程上把偏好作为一等适配维度，用 CSS 媒体查询 + 相应降级，并测试各偏好下的表现。这些是"感知可访问性"与"网络可访问性"的现代扩展。

这些偏好媒体查询把"用户偏好"转为可适配的无障碍/可达性维度。掌握它们能让应用在深色、增强对比、减少透明/数据等偏好下保持可用，是感知与可达性的现代实践。

• WebVTT 与 track 元素
• 字幕与音频描述
• WCAG 1.2 时序媒体

字幕用 <track kind="captions" src="a.vtt"> 配合 <video> 实现，WebVTT（.vtt）文件按时间轴包含字幕文本；音频描述（audio description）用 <track kind="descriptions"> 提供旁白描述画面内容。WCAG 1.2 时序媒体（基于时间的内容）合规要求：1.2.2 预录字幕（captions）——A 级必含；1.2.3 音频描述或媒体替代——A 级；1.2.4 实时字幕（AA）；1.2.5 音频描述（AA）；更高级别 1.2.6/1.2.7/1.2.8/1.2.9 是 AAA。实现要点：track 元素需提供 label、src 指向 .vtt、kind 正确；字幕/描述需与音画同步、文本准确、可读。音频描述也可用独立的"extended audio description"（暂停视频插入更长描述）。

时序媒体合规是"感知"原则的重要部分。WebVTT + track 是标准实现，字幕（captions）与音频描述（descriptions）分别解决"听不到"与"看不到"两类用户。合规等级从 A（字幕）到 AAA（手语）递增。

• 实时字幕概念
• SpeechRecognition API
• WebVTT 同步

实时字幕（Live Captioning）在会议/直播中实时显示发言文字，WCAG 1.2.4（AA）要求实时媒体有字幕。前端方案：用 Web Speech API 的 SpeechRecognition 识别语音，把识别结果实时追加到字幕区；用 WebVTT 或自定义同步机制把时间戳与文本关联，随播放/说话实时显示。实现要点：SpeechRecognition 的 continuous + interimResults 获取实时中间结果，处理识别延迟与错误；字幕区用 aria-live 让读屏用户感知（但避免过度播报）；保证字幕与音频同步。现实权衡：浏览器本地识别准确率有限，生产级常用服务端识别（如 Google/Whisper）或实时字幕服务，然后通过 WebVTT/RTMP 推流。工程上需处理延迟、错字、多说话人。

实时字幕是"时序媒体 + 实时"的无障碍难点。SpeechRecognition 适合原型/轻量场景，生产级需服务端识别 + 同步机制。最终要保证字幕实时、同步、可读，满足 WCAG 1.2.4。

• 可访问 PDF（PDF/UA）
• HTML 语义化 vs PDF
• 工程决策

可访问 PDF（PDF/UA = PDF 无障碍标准，及 WCAG 对 PDF 的映射）要求 PDF 有标签结构（tagged）、阅读顺序、alt 文本、正确表头等，辅助技术才能读取。工程取舍：当内容需要在网页中呈现且可交互时，优先用 HTML 语义化（自带无障碍、可缩放、可键盘操作），而非 PDF；PDF 适合"需要精确排版/打印/声明固定格式"的场景，此时需生成带标签的 PDF（PDF/UA）、提供 alt、保证阅读顺序。决策依据：内容形态（文档 vs 页面）、交互需求、可维护性、合规目标。HTML 通常更易实现无障碍，PDF 需专门的标签生成工具链。若两者皆可，优先 HTML；PDF 作为附件时需确保 PDF/UA 合规。

"HTML 优先"是无障碍的工程决策——HTML 语义化原生无障碍、易维护。PDF 仅在需要固定排版/打印时选用，且需符合 PDF/UA。决策本质是"内容类型 + 无障碍成本"的权衡。

• :focus-visible 与 :focus 区别
• 触发差异
• 焦点指示升级实践

:focus 在任意聚焦时触发（鼠标、键盘、触屏）；:focus-visible 只在"键盘导航"或"需要可见焦点"时触发（如键盘按键后），鼠标点击通常不触发。触发差异：键盘 Tab 触发 :focus-visible，鼠标点击默认不触发（除非浏览器认为需要）。工程实现"键盘导航下焦点指示不丢失"：用 :focus-visible 提供高对比度焦点环（outline），同时保留 :focus 的基础样式；避免裸删 outline（outline:none）导致键盘焦点不可见；用伪元素或自定义 outline 增强可见性；对自定义组件确保 :focus-visible 样式清晰。最佳实践：:focus-visible { outline: 2px solid ... }，结合 :focus 兜底，保证键盘用户永远能看到焦点，鼠标用户不被打扰。

:focus-visible 是无障碍与美观的平衡点——只在键盘时显示焦点环。关键是用 :focus-visible 提供清晰焦点 + 不裸删 outline + 兜底，保证键盘导航焦点指示不丢失。

• 播放器控件 aria-label
• aria-valuetext 的进度/音量
• 焦点管理

媒体播放器自定义控件（播放/暂停、进度、音量、全屏）需无障碍适配：每个按钮用 aria-label 命名（如"播放"、"音量"）；进度条/音量用 role="slider" + aria-valuenow + aria-valuetext（如"播放到 2:30"、"音量 50%"），或用 role="progressbar" 表达进度；键盘操作：播放按钮 Space/Enter、进度条方向键、音量键、Esc 退出全屏；焦点管理：进入播放器时焦点到播放按钮，控件间 Tab 顺序合理，全屏时焦点管理。字幕/描述轨道用 aria-label 命名。读屏需能播报控件名称、当前进度/音量、状态。原则：优先原生 <video> 控件的浏览器实现，自定义时完整实现 aria 与键盘。

媒体播放器是"复杂控件集合"。重点在按 slider/progressbar 语义提供 aria-valuetext 的可读值、按钮 aria-label、以及完整键盘/焦点。优先原生控制，自定义时补齐语义。

• WebVTT 样式（::cue）
• 定位与行/区域
• 跨浏览器兼容

WebVTT 支持通过 ::cue 伪元素为字幕设置样式（颜色、背景、字体、字号、对齐），并可在 .vtt 中用 NOTE/CUE 定位（如 line、position、align、voice 区域）控制字幕位置。自定义字幕渲染（如自己实现字幕层而非原生 track）需处理：解析 .vtt（解析 cue 时间轴与 payload）、按时间显示/隐藏 cue、应用 ::cue 样式、处理定位（line/position）、处理转义与多行。跨浏览器兼容性：原生 <track> 的 ::cue 样式支持在不同浏览器有差异（如部分属性不支持、默认样式差异）；自定义渲染需自己实现样式与定位，兼顾一致性但需自己处理浏览器差异（如 ::cue 的 color/background 支持）。关键是保证字幕可读、可样式化、位置正确，且跨浏览器表现一致。

字幕样式与定位是"可读性"细节。原生 track 的 ::cue 样式支持有限且跨浏览器不一致，自定义渲染提供更多控制但需自己处理解析与兼容。工程权衡看需求复杂度。

• forced-colors 媒体查询
• forced-color-adjust 属性
• Canvas/SVG 在强制色彩的问题

forced-colors 媒体查询匹配系统强制色彩模式（如 Windows 高对比度模式），此时用户自定义颜色被系统强制调色板覆盖。forced-color-adjust: none 可让元素保留作者颜色（除非被强制），但需谨慎使用。适配要点：应用应使用系统颜色（CanvasText、ButtonText、HighlightText 等 CSS 系统颜色）以适配强制模式；避免用纯背景色/图片承载信息；图标/控件需在强制模式下可辨。Canvas/SVG 问题：Canvas 绘制的内容不受 CSS 色彩强制影响，需手动检测 forced-colors 并调整绘制颜色；SVG 的 fill/stroke 在强制模式下可能不被覆盖，需处理（如用 CSS currentColor 或 system colors）。测试：在系统高对比度/强制色彩下验证可读性。

forced-colors 是"系统级色彩强制"的适配场景。核心是使用系统颜色、正确处理 Canvas/SVG 等不受 CSS 强制影响的内容，保证强制色彩模式下信息仍可读可辨。

• 字体缩放/浏览器缩放的影响
• fluid 布局与 container queries
• 200% 缩放下防截断

用户字体缩放与浏览器缩放（200% 重缩放）会放大文本/布局，若用固定宽度/px 布局易导致内容溢出、截断、重叠，破坏可达性。WCAG 1.4.4 重缩放要求文本可放大 200% 不丢失功能。工程实践：1）fluid 布局——用相对单位（rem/%/flex/grid）而非固定 px，让布局随可用空间自适应；2）container queries——基于容器宽度（而非视口）响应式调整组件，提升组件级自适应；3）max-width——用 max-width: 100% 防止图片/表格/内容溢出；4）避免固定高度（防止文字截断）、用 min-height + 溢出处理；5）用 clamp() 控制字号缩放。目标：200% 缩放/大字号下内容不截断、不溢出、可滚动查看。

重缩放破坏布局是常见的可达性缺陷。fluid + 相对单位 + container queries + max-width 是"自适应布局"的工程手段，核心是让布局随内容/空间伸缩而非固定，保证 200% 缩放可用。

• 阅读障碍的设计
• ADHD 的设计
• 认知可访问性

认知障碍设计考虑：阅读障碍（dyslexia）——用清晰易读的字体、适当行距/字距、高对比度、分段短句、避免大段文字、提供文本替代（列表、图示）、避免斜体/装饰字体；ADHD（多动症）——减少干扰、避免过度动画/自动播放、提供聚焦当前任务的引导、一致的导航、错误预防、分步呈现复杂任务、允许暂停/跳过。认知可访问性（WCAG 3.1 可读、3.2 可预测、3.3 输入辅助）强调：清晰语言、一致导航、错误预防与纠正、提供足够时间。工程上：提供 prefers-reduced-motion 降级、允许自定义字号/行距、保证内容结构化、避免内容突然变化。设计上渐进的细节呈现、减少认知负担。

认知障碍设计关注"理解与负担"，而非仅视觉。核心是清晰语言、一致结构、减少干扰、提供时间与错误预防。它比纯视觉无障碍更强调"可理解"原则。

• 对比度标准（4.5:1/3:1）
• 深色模式对比度
• 适配实践

WCAG 对比度要求：正文文本与背景至少 4.5:1（1.4.3，AA），大号文本/图形至少 3:1（1.4.11 非文本对比度，AA）。深色模式适配：深色背景下的文字、图标、边框、状态指示需满足对比度，且深色模式常出现对比度不足（如深灰背景 + 中灰文字）。适配实践：用对比度工具验证深浅色两套配色；深色模式用更高明度的文字、避免纯黑背景 + 纯白文本（实际有炫光，通常用深灰 #121212 + 亮灰文本）；非文本内容（图标、焦点环、输入框边界）也要对比度达标；用 prefers-color-scheme 切换配色并统一认证对比度。深色模式不是"简单反色"，需重新设计对比度。

对比度是可感知的基础，深色模式是"对比度易翻车"的常见场景。适配关键是验证浅/深两套配色的文本与非文本对比度，而非简单反色。

• 清晰语言
• 一致导航
• 错误预防

认知可访问性（WCAG "可理解"原则）三方面：清晰语言——用简单、明确、无歧义的语言，避免术语/缩写无解释，重要信息用多种方式（文字+图标）呈现（3.1 可读语言）；一致导航——导航在页面间保持一致（位置、顺序、标识），避免突然变化导致用户迷失（3.2 可预测）；错误预防——在有代价的操作（提交、删除、购买）前提供确认、撤销与可恢复机制，减少认知与控制负担（3.3 输入辅助）。工程实现：语言文案可读性、一致的组件/导航布局、销毁性操作二次确认、表单可预览/可撤销。这些降低认知障碍用户的理解与操作负担。

认知可访问性聚焦"可理解 + 可预测 + 可预防错误"。它比视觉无障碍更强调信息呈现与操作流程的设计，是"可理解"原则的落地。

• WCAG 2.2.2 暂停/停止/隐藏
• prefers-reduced-motion 协同
• 实现

WCAG 2.2.2（Pause, Stop, Hide）要求：自动播放的动画/视频、自动更新内容、闪烁内容，若超过 5 秒或与其他内容并行，需提供暂停/停止/隐藏控制（或用户可控制）。prefers-reduced-motion 是用户偏好减少动效的媒体查询。协同实现：1）自动播放的轮播/动画/视频提供暂停/停止按钮，尊重用户控制；2）用 prefers-reduced-motion 时关闭或降级动画（减少运动、改为静态/淡入淡出）；3）无论是否 reduced-motion，耗时或自动播放内容都应提供控制。工程上：用 CSS @media (prefers-reduced-motion: reduce) 禁用动画，用 JS 检测并跳过自动播放/减少动效，提供显式暂停控件。二者结合是"用户偏好 + 规范要求"的双重保障。

2.2.2 要求"可控制"，prefers-reduced-motion 要求"尊重偏好"。协同是"既提供控制，又尊重系统偏好"，避免自动播放/过度动画困扰运动敏感与认知障碍用户。

• 非文本对比度（1.4.11）
• 与文本对比度的差异
• 检测方法

WCAG 1.4.11（非文本对比度，AA）要求 UI 组件边界、状态指示、图形对象（图标等）与相邻颜色至少 3:1 对比度，用于"识别界面信息"的非文本内容。差异：文本对比度（1.4.3）用 4.5:1（正文）/3:1（大文本），非文本对比度是 3:1（AA），且针对的是"区分控件/状态/图形"而非阅读文字。检测方法：对控件边界、输入框边框、图标、焦点环、状态（选中/错误）等测量与背景的对比度；需"可识别"（图标本身颜色与背景）且"可区分"（控件边界与背景）。常用 axe 的 color-contrast 规则（含非文本）、对比度工具（如 WebAIM、Figma 插件）检测。注意：状态指示若仅靠颜色还需非颜色提示（1.4.1）。

非文本对比度解决"界面元素可辨识"。它与文本对比度标准不同（3:1 vs 4.5:1），检测重点在控件边界/图标/状态。理解其差异与检测方法，是"可区分"原则的完整落地。

• WCAG 1.4.12 文本间距
• 溢出/截断问题
• 布局保障

WCAG 1.4.12（Text Spacing，AA）要求：用户或应用把行高增加至 1.5 倍、段距 2 倍、字距 0.12 倍、词距 0.16 倍时，内容不丢失、不溢出、不截断。实现保障：1）避免固定高度/固定行高导致文字被裁切（用 min-height 或用 overflow 处理）；2）避免 white-space: nowrap 与固定宽度导致文字溢出；3）避免用固定高度容器 + 隐藏溢出来"截断"文本；4）用相对单位/自适应布局让文本间距变化时能扩展；5）测试时用 JS/CSS 模拟上述间距倍数验证布局。核心是"让文本可重排、高度可扩展"，保证放大间距后信息完整可读。

文本间距标准针对"用户自定义间距导致的内容丢失"。保障核心是避免固定高度/宽度/nowrap 导致的截断溢出，让布局随文本间距自适应。这是"可感知"的布局细节。

• WCAG 1.4.1 使用彩色
• 图标/文本辅助
• 实现

WCAG 1.4.1（Use of Color，A）要求"颜色不能作为传递信息的唯一手段"。即信息（如成功/错误状态、必填项、链接、选中态）若只用颜色区分，色盲/低视觉用户无法获取。实现：用图标 + 颜色、文本 + 颜色、模式 + 颜色（如错误加红框 + 红色文字 + 错误图标 + 文字说明）；必填项用星号或"必填"文字而非仅红字；链接用下划线 + 颜色；选中态用边框/填充 + 图标。工程上：状态组件同时提供颜色与图形/文本提示，并测试"去色后信息是否仍可获取"。这是"不依赖颜色"的通用无障碍实践。

1.4.1 是"不依赖颜色"的经典准则。核心是信息冗余编码——用颜色 + 图标/文本/模式多种通道表达同一信息，保证任何感知通道的用户都能获得。去色测试是验证手段。

• 音频描述与扩展音频描述
• 制作成本
• 工程取舍

音频描述（audio description）在视频原有音轨的间隙插入旁白，描述画面内容（人物、动作、场景），供视觉障碍用户理解；扩展音频描述（extended audio description）在视频暂停时插入更长描述（用于支持更多内容时）。工程成本：两者都需要专业编写描述文本、配音录制、与视频时间轴同步（在音轨间隙插入）、后期混音；扩展音频描述还需处理视频暂停/切片的编辑，成本更高。制作成本高：需要脚本撰写、配音、音效混音、时间轴对齐、多语言版本。WCAG 1.2.3（A）要求预录视频有音频描述或替代，1.2.5（AA）要求音频描述。工程取舍：优先保证字幕（captions），音频描述按预算与合规目标安排；简短视频可用"文本替代"（1.2.3 的替代方案）降成本。

音频描述成本高（编写+配音+同步），是视频无障碍的"高成本项"。理解其制作流程与成本，能在合规目标下做取舍（字幕必做，音频描述按需/替代方案）。

• 手语翻译的实现
• WCAG 1.2.6（AAA）
• 工程边界

手语翻译（sign language interpretation）在视频中通常以"画中画"（PIP）方式放入手语翻译员的视频画面，与主视频同步。WCAG 1.2.6（Sign Language，AAA）要求预录媒体提供手语翻译。它是 AAA 级准则，非 AA 强制，工程边界/难点：1）翻译需由专业手语译员制作，成本高、稀缺；2）需与主视频同步、画面清晰可辨；3）PIP 布局需考虑主视频可见性；4）多语言/多种手语变体（如 ASL、BSL）需分别制作；5）以 AAA 为目标的组织才需要。工程取舍：AAA 级手语翻译是"高成本增强"，多数组织以 AA 为准（字幕+音频描述），手语翻译仅在特定内容或 AAA 目标下实施。工程上若提供，用 WebVTT 的 kinds 或独立 PIP 视频轨道实现并同步。

手语翻译是 AAA 级"高成本"无障碍，工程边界在于"成本高 + 稀缺 + 多语言变体"。理解其 AAA 定位与实现成本，能在合规目标下做清醒取舍（AA 多数场景已够）。

• WCAG 2.3.1 防癫痫
• 闪烁频率阈值
• 动画禁用开关

光敏性癫痫风险：闪烁内容可能触发癫痫发作，WCAG 2.3.1（Three Flashes or Below Threshold，A）要求内容不含每秒闪烁超过 3 次（或低于一般闪烁阈值）的闪烁。2.3.2 （Three Flashes，AAA）更严格。规避方式：1）控制动画/闪烁频率（避免每秒 3 次以上频闪，避免大面积高对比闪烁）；2）避免低频率（约 2-8Hz）高对比度闪烁（最危险）；3）提供"禁用动画/闪烁"开关——用户可关闭动画、减少运动；4）用 prefers-reduced-motion 降级动画；5）避免红蓝交替等高危闪烁。工程实现：动画用 CSS 控制并尊重 reduced-motion，闪烁内容提供暂停/关闭，测试时检查频率与面积。这是"健康安全"导向的无障碍。

防癫痫是"安全"级无障碍。核心是频率阈值（≤3 次/秒）+ 提供禁用开关 + 尊重 reduced-motion。这既保护光敏用户，也减少对运动敏感人群的干扰。