不只是“能用”：从语义化到 ARIA，打造“信息无障碍”Web 应用的实战清单-EW帮帮网

不只是“能用”：从语义化到 ARIA，打造“信息无障碍”Web 应用的实战清单

作为前端开发者，我们每天都在用代码构建一个五彩斑斓的数字世界。我们痴迷于像素级的精准、流畅的动画和极致的性能。但我们是否想过，对于某些用户来说，这个世界可能是一片漆黑，或者充满了无法逾越的障碍？

闭上眼睛，想象一下你是一位视障者。你如何“阅读”一个新闻网站？你依赖一个叫做“屏幕阅读器”的软件，它会大声朗读出页面上的内容。当你听到“图片，文件名为 img_7532.jpg”时，你一无所知。但如果你听到“图片，一只金毛寻回犬在草地上接飞盘”，这个世界瞬间就清晰了。当你按 Tab 键想在表单中跳转时，焦点却在一个看不见的 <div> 上反复横跳，你该有多么沮丧？

这不是危言耸听，这是全球超过10亿残障人士每天都在面对的数字鸿沟。

Web 无障碍（Accessibility，简称 a11y），不是一个可有可无的“加分项”，也不是什么高深莫测的技术，它是一个专业开发者必备的职业素养，是衡量一个产品是否真正“用户友好”的黄金标准。它确保我们构建的应用，无论用户的身体能力、网络条件或设备如何，都能平等、便捷地获取信息和使用功能。

这篇文章不准备讲太多空洞的口号。我将为你提供一份超级实用的实战清单 (Checklist)，将无障碍的最佳实践分解成一个个具体、可操作的任务。你可以对照这个清单，逐一检查和优化你的Web应用，让它从“能用”真正走向“好用”，为所有用户。

Part 1: 地基工程 —— 语义化 HTML

无障碍的基石，始于编写“有意义”的HTML。屏幕阅读器等辅助技术，正是通过解析HTML的语义来理解页面结构的。当你的页面充满了无意义的 <div> 和 <span> 时，在辅助技术看来，它就像一篇没有标题、没有段落、没有重点的万字长文，无法卒读。

✅ 清单 1：用对的标签，做对的事

告别 div 走天下。审视你的页面，问问自己：这块内容到底是什么？

这是页头吗？ 用 <header>，不要用 <div class="header">。
这是导航栏吗？ 用 <nav>。
这是主要内容区域吗？ 用 <main> (一个页面只用一次)。
这是一篇独立的文章或卡片吗？ 用 <article>。
这是与主要内容相关的侧边栏吗？ 用 <aside>。
这是页脚吗？ 用 <footer>。
这是一个可点击的按钮吗？ 请务必用 <button>，而不是 <div @click="...">。<button> 标签天生支持键盘 Enter/Space 键触发，且能被辅助技术识别为“按钮”。用 <div> 模拟按钮，会丢失所有这些原生特性。

反例 ❌:

<div class="card">
  <div class="title">文章标题</div>
  <div class="content">...</div>
  <div class="button" onclick="doSomething()">点我</div>
</div>

正例 ✅:

<article>
  <h2>文章标题</h2>
  <p>...</p>
  <button onclick="doSomething()">点我</button>
</article>

✅ 清单 2：为所有图片提供有意义的 `alt` 文本

alt 属性是图片的“身份证”。

对于有实际意义的图片（如产品图、新闻图），alt 文本应该清晰地描述图片内容。
- 正例 ✅: <img src="dog.jpg" alt="一只金毛寻回犬在草地上接飞盘">
- 反例 ❌: <img src="dog.jpg" alt="图片">
对于纯装饰性的图片（如背景纹理、分割线），alt 属性应该设置为空 (alt="")。这样，屏幕阅读器会直接忽略它，而不会读出无用的文件名来干扰用户。

✅ 清单 3：正确使用标题层级 `<h1>` - `<h6>`

标题标签 (Heading tags) 为页面内容构建了大纲结构。

确保 <h1> 在一个页面上只出现一次，作为页面的总标题。
遵循从 <h2> 到 <h6> 的逻辑层级，不要跳级（比如从 <h2>直接到 <h4>），这会破坏文档的逻辑结构。
不要仅仅因为样式需求而滥用标题标签（比如用 <h3> 来实现一个加粗的普通文本）。如果只是需要样式，请使用 CSS。

Part 2: 交互核心 —— 键盘可访问性

“如果一个功能不能只用键盘完成，那它就是不可访问的。” —— 这是 Web 无障碍的一条铁律。因为不仅视障用户依赖键盘，许多运动障碍者也无法使用鼠标。

✅ 清单 4：确保所有交互元素都能被 `Tab` 键聚焦

浏览器原生就为 <a href="...">, <button>, <input>, <select>, <textarea> 等交互元素提供了 Tab 键聚焦的能力。

当你使用 div 或 span 模拟一个自定义组件（如自定义下拉菜单）时，问题就来了。这些非交互元素默认是无法被 Tab 键聚焦的。
解决方案：为这个 div 添加 tabindex="0" 属性。tabindex="0" 意味着“这个元素可以被聚焦，并且其 Tab 顺序由它在文档流中的位置决定”。
注意：避免使用大于0的 tabindex (如 tabindex="1", tabindex="2")，这会强制打乱自然的 Tab 导航顺序，造成用户困惑。

✅ 清单 5：为自定义组件实现键盘交互

如果一个元素能被聚焦，它就必须能被操作。

如果你的 <div tabindex="0"> 扮演的是一个按钮的角色，那你必须监听键盘事件，当用户按下 Enter 或 Space 键时，触发与 click 事件相同的功能。

const customButton = document.getElementById('custom-button');

customButton.addEventListener('click', doAction);
customButton.addEventListener('keydown', (event) => {
  // 如果是回车键或空格键
  if (event.key === 'Enter' || event.key === ' ') {
    doAction();
    // 阻止空格键导致页面滚动的默认行为
    event.preventDefault(); 
  }
});

✅ 清单 6：管理好你的焦点

在单页应用 (SPA) 中，焦点管理尤为重要。

弹窗 (Modal) 打开后：焦点必须立即移动到弹窗内的第一个可聚焦元素上。同时，要将 Tab 键的焦点“囚禁”在弹窗内部，不能让它跑到弹窗背后的页面内容上。
弹窗关闭后：焦点必须返回到当初打开这个弹窗的那个元素上（比如“打开弹窗”按钮）。
路由切换后：当用户导航到一个新页面时，焦点应该被设置到页面的主内容区域或主标题上，并最好能通过 aria-live 告知用户“已导航到XX页面”。

Part 3: 进阶增强 —— ARIA 的魔法

ARIA (Accessible Rich Internet Applications) 是一套属性，它可以增强 HTML 的语义，让辅助技术能更好地理解那些复杂组件的角色(role)、状态(state)和属性(property)。

记住黄金法则：能用原生 HTML 实现的，就不要用 ARIA。只有在原生 HTML 无法表达语义时，才需要 ARIA 来“打补丁”。

✅ 清单 7：为自定义组件赋予“角色” (role)

当你用 div 组合出一个复杂的 UI 组件时，你需要告诉辅助技术“这玩意儿到底是个啥？”。

自定义复选框：<div role="checkbox" ...>
自定义Tab选项卡：<div role="tablist"> 包裹着 <div role="tab"> 和 <div role="tabpanel">。
自定义滑块：<div role="slider" ...>

✅ 清单 8：用 `aria-*` 属性描述“状态”

ARIA 属性可以描述组件的当前状态，并且这些状态是会动态变化的。

aria-checked：表示一个自定义复选框或单选按钮是否被选中。(true/false)
aria-expanded：表示一个可折叠的菜单（如手风琴、下拉菜单）当前是展开还是折叠状态。(true/false)
aria-selected：表示 Tab 选项卡中的某个 Tab 当前是否被选中。(true/false)
aria-hidden：将一个元素对辅助技术完全隐藏。当一个元素在视觉上被隐藏（如 display: none）时，通常也应该加上 aria-hidden="true"。
aria-disabled: 表示一个元素当前被禁用。

示例：一个自定义复选框

<div 
  role="checkbox" 
  tabindex="0"
  aria-checked="false" 
  id="custom-checkbox">
  <!-- ... 内部的勾选图标等 ... -->
  选择我
</div>

<script>
  const checkbox = document.getElementById('custom-checkbox');
  checkbox.addEventListener('click', () => {
    const currentState = checkbox.getAttribute('aria-checked') === 'true';
    checkbox.setAttribute('aria-checked', !currentState);
  });
  // ... 还要添加键盘事件处理 ...
</script>

✅ 清单 9：提供清晰的“标签” (Accessible Name)

有时候，一个按钮可能只有一个图标，没有可见的文本。视觉正常的用户能看懂，但屏幕阅读器却不知道怎么读。

反例 ❌: <button>×</button> (屏幕阅读器可能会读作“叉”或“乘号”)
解决方案: 使用 aria-label。

<button aria-label="关闭">×</button>

现在，屏幕阅读器会清晰地读出“关闭，按钮”。aria-label 的优先级高于元素内的文本内容。

Part 4: 视觉关怀

✅ 清单 10：保证足够的色彩对比度

根据 WCAG (Web Content Accessibility Guidelines) 标准，普通文本与其背景色的对比度至少应为 4.5:1。

如何检查？ Chrome DevTools 自带了这个功能！在 Elements 面板中，点击颜色选择器，它会显示当前的对比度值，并给出 “AA” 或 “AAA” 的评级。
避免的组合: 浅灰色文字配白色背景，或者深蓝色文字配黑色背景，这些都是常见的对比度不足的例子。

总结

打造信息无障碍的应用，不是一项繁重的负担，而是一种开发者内功的体现，是一种专业精神和人文关怀的结合。它要求我们从一开始就思考得更全面、更严谨。

让我们把这份实战清单浓缩成核心要点：

从语义化 HTML 开始: 这是零成本但收益最高的实践。
保证键盘可控: 所有交互都必须能只通过键盘完成。
善用 ARIA 打补丁: 在原生 HTML 不够用时，用 ARIA 准确描述组件的角色、状态和属性。
管理好焦点: 在 SPA 应用中，主动、合理地管理焦点是提升体验的关键。
关注视觉细节: 保证色彩对比度，照顾视力不佳的用户。

无障碍开发并非一蹴而就。它需要我们持续学习，并在项目中不断实践。但每一点努力，都在为构建一个更公平、更包容的互联网世界添砖加瓦。希望这份清单，能成为你开启无障碍开发之旅的实用地图。

不只是“能用”：从语义化到 ARIA，打造“信息无障碍”Web 应用的实战清单