4.2 可访问性 A11y
4.2 可访问性 A11y
本节摘要：可访问性指残障用户对页面的可用程度，工程上等于"辅助技术能否正确理解你的 HTML"。本节讲清谁在依赖它、语义结构为何是地基、ARIA 的补丁定位、键盘与焦点管理的硬规则、图片与多媒体的替代方案，以及一套自测流程。多数可访问性实践零成本——它们本来就是"把结构写对"。
学习目标
阅读完本节，你应当能够：
- 说出主要辅助技术及其依赖的页面信息；
- 落地可访问性的地基清单（地标、标题、label、原生控件）；
- 遵守 ARIA 的使用纪律，识别"ARIA 滥用"的坏味道；
- 检查键盘可达性与焦点可见性；
- 为图片、表单、多媒体写出合格的替代表达；
- 用键盘走查加自动化扫描完成一轮自测。
先认识你的用户
可访问性常被误解为"为极少数人做的慈善"。两组事实纠正这个印象。其一，残障人口的比例远超直觉：视障、色觉障碍、听障、运动障碍、认知障碍人群合计约占人口的一到两成；此外还有情境性障碍——强光下看不清屏幕的行人、单手抱娃只能用键盘的父母、开了大字模式的老人，他们和永久性残障用户共享同一条通道。其二，无障碍通道的受益面从来不限于目标人群：坡道方便了行李箱，字幕方便了静音场合，alt 文本方便了搜索引擎——第 2 章讲的"三方契约"在这里兑现。
辅助技术的主角是读屏软件：它把界面转成语音（或盲文），视障用户"听"网页。读屏的体验完全取决于你的 HTML 质量：语义结构提供地图（地标导航、标题跳转），控件语义提供操作（button 可触发、checkbox 可切换），文本替代提供内容（alt 被朗读）。全 div 页面在读屏里是一篇没有段落的长文——不是"体验差"，是基本不可用。
地基清单：语义即无障碍
可访问性最大的秘密：把第 2 章的语义结构写对，就完成了八成。地基清单七条，全部零成本：
- html 根元素声明 lang（读屏切换发音引擎）；
- 每页一个 h1、标题不跳号（标题跳转的依据）；
- 地标齐全：header、nav、main、aside、footer（读屏的地标导航）；
- 原生控件优先：button、a、input、select（键盘行为内置）；
- label 关联每个控件（点击聚焦加朗读名称）；
- 图片有 alt（内容图写描述、装饰图写空值）；
- 表格用 th 与 caption（表头关联朗读）。
第 5、6 两条展开说。label 的关联让控件获得"可朗读的名字"——读屏不会念"编辑框"三个字就完事，而是念"邮箱，编辑框"。关联两种写法：label 包住控件，或 label 的 for 指向控件的 id。图片 alt 的分级：内容图写实质描述（"折线图：2020 至 2025 年访问量增长五倍"）、功能图写动作（"搜索"）、纯装饰图写空 alt（alt 加空值，读屏直接跳过；不写 alt 反而会被念出文件名）。
ARIA：补丁不是替身
语义元素覆盖不到的地方，ARIA 属性补位。它给元素补充"声明语义"：role 声明角色，aria-* 系列声明状态与属性。两个最有用的例子：
<!-- 动态更新的状态区：aria-live 让读屏主动播报变化 --> <p aria-live="polite" id="status">正在保存……</p> <!-- 图标按钮：aria-label 提供可访问名称，视觉上没有文字 --> <button aria-label="关闭对话框">✕</button>
aria-live 是做异步交互的必配：保存成功、加载完成这类状态变化，视觉用户看到提示条，读屏用户需要 aria-live 才能听到播报。aria-label 补救"只有图标没有文字"的控件——没有它，读屏只念出"按钮"，用户不知道按了会怎样。
但 ARIA 的第一纪律是克制。第 1 章立过"原生优先"原则，这里的完整版是 ARIA 官方的第一法则："能用原生元素，就不要用 role 加 div 重造。"重造的代价清单很长：div 加 role 值为 button 不会自动获得焦点与键盘触发（Enter 与空格键都要手写监听）、不会随禁用状态变化、读屏的支持还参差。实战里 ARIA 滥用的信号词：满页 role、每个 div 都挂 aria-*、给语义元素再标一遍重复的 role（nav 上标 role 值为 navigation 属于画蛇添足）。记住剂量原则：ARIA 出现的地方，应该能说出"哪个原生元素做不到这件事"。
键盘与焦点：不可协商的底线
运动障碍用户不用鼠标，全键盘操作。键盘可用性的三条硬规则：
可达：所有交互元素必须能被 Tab 聚焦到。原生控件天生可达；div 加 onclick 的"伪按钮"不可达——这是它最大的罪。真需要自定义可聚焦元素，加 tabindex 值为零；负值元素（-1）可编程聚焦但不进 Tab 序列，用于模态框内的焦点管理。
可见：焦点位置必须看得见。浏览器默认有焦点轮廓，被全局样式去掉又不补的站点等于把键盘用户蒙眼。悬停样式与聚焦样式成对出现（第 3 章讲过），或至少保留默认轮廓——为美观去掉焦点样式又不补替代，是无障碍评审的一票否决项。
有序：Tab 顺序跟随文档流。用正 tabindex 值手工指定顺序是大坑（整页顺序都被这些数字劫持，维护噩梦）；正确做法是让标记顺序就是操作顺序——这又回到"结构写对"。
<style> /* 悬停与聚焦成对：视觉反馈不给键盘用户打折 */ .btn:hover, .btn:focus-visible { background: #2980b9; color: #fff; } </style>
对比度与多媒体
视觉维度的硬指标是文字对比度：正文要求至少 4.5 比 1，大字号标题 3 比 1（WCAG 标准的量化条款）。低对比灰字小字是设计感与可读性的经典冲突，取舍标准是字号越小对比越要足。色觉障碍维度还有一条"不单靠颜色传达信息"：错误状态不能只标红，加图标或文字（"错误："前缀），色盲用户才不迷失。
多媒体的替代方案在第 2 章铺过：视频配字幕轨、音频配文字实录、canvas 配文本表述。这里补一条交互件的：表单错误提示不要只靠标题闪红——错误文案要靠近字段、用文字写明（"邮箱格式不正确"），并让焦点跳到第一个错误字段。只靠颜色的报错在读屏与色觉障碍两个维度同时失守。
自测流程：一轮十五分钟
可访问性测试的入门流程，不需要专业设备：
第一步，拔掉鼠标。把鼠标放到一边，只用 Tab、Enter、空格、方向键走完页面的核心流程（浏览、导航、提交一个表单）。走不通的地方记下来——这一步能抓住六成的常见问题，比任何工具都灵敏。
第二步，跑一次自动化扫描。浏览器开发者工具内置的可访问性检查、或开源的扫描工具，能自动查出缺失的 alt、label、对比度不足、无名称控件。自动化只能覆盖可机器判定的三成问题，但它便宜，值得每次改动都跑。
第三步，抽查看屏体验。操作系统自带读屏（视障用户日常用的正是它们），开起来听首页两分钟：能不能听出页面结构、控件有没有名字、图片念出来是描述还是文件名。不必成为读屏高手，"听起来是否迷惑"这个判断不需要训练。
⚠️ 常见坑：把可访问性当"上线前补一遍"的收尾工作。补丁式改造的成本是设计期就做对的三到五倍（结构性的焦点顺序、语义结构往往牵动重构）。正确姿势是像第 2 章那样从第一行标记就写对——地基清单本来就是免费的。
动手实验：体验一次"盲用"
纸上谈完，强烈建议做一次角色扮演实验——不用任何残障辅助工具，只靠两个字：蒙眼体验。打开操作系统自带的读屏软件，闭眼完成一个任务：在一个新闻站上找到某条新闻的标题并进入正文。你会经历完整的"盲用"流程：听到页面加载后读屏念出的标题、试着用地标快捷键跳过导航、在标题层级间跳跃、误入广告区再退出来。十分钟的挫败感胜过十小时的概念学习，你会立刻明白为什么本章把"地标齐全、标题不跳号、控件有名字"列为零成本的地基——因为在纯听觉的世界里，它们就是全部的路标。
<!DOCTYPE html> <html lang="zh-CN"> <head><meta charset="UTF-8"><title>可访问性对照实验</title></head> <body> <!-- 版本A：伪控件，读屏只念"按钮"或干脆不可达 --> <div class="btn" onclick="alert('A被点了')">伪按钮A</div> <!-- 版本B：原生控件加名称，读屏念"提交表单，按钮" --> <button type="button" onclick="alert('B被点了')">提交表单B</button> <!-- 版本C：图标按钮无名称，读屏念"按钮"，用户不知道是什么 --> <button type="button" onclick="alert('C')">✕</button> <!-- 版本D：图标按钮配 aria-label，念"关闭，按钮" --> <button type="button" aria-label="关闭" onclick="alert('D')">✕</button> <!-- 动态状态：无aria-live，读屏不知道保存完成 --> <p id="saveState">点击上面的按钮后看我</p> <script> document.querySelectorAll('button').forEach(b => b.addEventListener('click', () => { const s = document.getElementById('saveState'); s.textContent = '已保存 ' + new Date().toLocaleTimeString(); })); </script> </body> </html>
开读屏逐一激活四个按钮：A 多半不可达或没有名称；B 名称完整；C 只有"按钮"二字；D 念出"关闭"。再观察点击后状态文字更新时读屏是否播报——没有 aria-live 时它沉默，视觉用户看到变化而听障于屏幕的用户一无所知。给状态段落加上 aria-live 属性为 polite 再试，播报出现。四个按钮加一个状态区，五分钟把本节全部概念过了一遍手。
高频疑问两则
收束一句：可访问性做得好的页面，通常也是结构与代码质量最好的页面——这不是巧合，而是同一份地基在支撑两边。
问：我们的用户里没有残障人士，还要做吗？
先质疑前提："没有"几乎总是"不知道"——分析工具看不见辅助技术用户，他们恰恰是最依赖可访问性的一群。另外合规风险真实存在：多国法规将网站可访问性列为强制要求，政府与大企业采购也常把无障碍列为门槛。最后的兜底理由：语义化、键盘支持、对比度这些实践同时提升所有用户的体验与 SEO，这笔投入不依赖"是否有残障用户"才成立。
问：ARIA 学到什么程度够用？
掌握三件套够应对九成场景：aria-label（补名称）、aria-live（播报变化）、aria-expanded 与 aria-hidden（状态与隐藏）。更深的 ARIA（复杂组件的模式）在需要时查官方实践模式文档即可，不建议预支学习——记住补丁纪律比记住属性全集重要。
本节要点回顾
（再次提醒：本节的动手实验价值最高——四个按钮加一个状态区，五分钟把语义、名称、播报三个概念全部过完手，比再读一遍文字有效。）
- 语义即无障碍：第 2 章的七条地基清单完成八成，零成本。
- ARIA 是补丁：aria-label、aria-live、状态族三件套够用；能用原生元素就不重造，每处 ARIA 都该答得出"原生哪里做不到"。
- 键盘三硬规：可达（Tab 能到）、可见（焦点看得见）、有序（跟文档流）；删焦点轮廓不补是一票否决项。
- 替代方案分级：图片按内容/功能/装饰三档写 alt，多媒体配字幕与实录，错误提示不单靠颜色。
- 自测三步：拔鼠标走查、自动扫描、抽听取屏——十五分钟抓住大部分问题。
- 设计期做对：补丁式改造成本数倍于起步就做对。
下一节换一位消费者：搜索引擎如何读你的页面，你又该喂它什么、不该喂它什么。