QualiBooth
简体中文

guides

应避免的常见无障碍问题

了解最常见的、会阻碍残障用户的网页无障碍错误，以及如何在它们成为合规风险之前加以修复。

3 min read QualiBooth
一份应避免的常见网页无障碍问题清单，包括对比度、替代文本和键盘导航。

为什么相同的无障碍问题会反复出现

大多数障碍并不稀奇。年复一年，自动化和人工审计都会暴露出同一份简短的错误清单：缺失的替代文本、低对比度、未标注的表单字段、键盘陷阱以及结构混乱。它们反复出现，是因为被悄无声息地引入——开发人员发布了一个新组件，营销人员上传了一张图片，设计师选了一种品牌颜色——而正常的工作流程中没有任何环节会标记出这个问题。对于使用鼠标和敏锐视力的人来说，视觉效果看起来没问题，于是这道障碍就这样上线了。

本目录梳理了我们在真实审计中看到的最常见的 WCAG 2.2 不合规情况。对于每一项，你都会看到它为何重要、影响哪些人、相关的成功标准，以及一个具体的修复前后对比。这些问题加在一起，构成了阻碍残障用户的绝大多数障碍——也构成了依据 European Accessibility Act、ADA 和 Section 508 提起的绝大多数法律投诉。

在列出清单之前有一点需要说清楚：自动化工具无法发现所有这些问题。独立研究一致表明，即便是最好的扫描器，也只能可靠地检测出 30–40% 的 WCAG 问题。它们擅长捕捉缺失的 alt 属性、可程序化检测的对比度问题以及缺失的表单标签，但它们无法判断替代文本是否准确、焦点顺序是否合理，或某个自定义控件在屏幕阅读器中是否真正可用。这正是为什么每一个可靠的方案都会将扫描与人工审查相结合。我们的 无障碍扫描软件 负责可自动化的部分；人工审计 和 由残障人士执行的审计 则覆盖其余部分。

在继续阅读之前，有一个快速找到自己起点的方法：在禁用图片的情况下查看页面，把每个字都当作一个没有结构的段落来读，并尝试只用键盘完成每项任务。凡是体验崩溃的地方，你就找到了一道障碍。

可感知：人们看不见或读不到的内容

缺失或不准确的图片替代文本

影响哪些人： 使用屏幕阅读器的失明或低视力人士；任何在图片无法加载的慢速连接上的人。

WCAG 标准： 1.1.1 非文本内容（A 级）。

没有 alt 属性的图片对辅助技术来说是不可见的——用户甚至可能根本不知道这张图片存在。比缺失属性更糟糕的是不准确的属性：诸如 IMG_4821.jpg 这样的文件名、像“图片”这样的笼统词语，或塞满关键词的字符串，都会主动误导收听者。

规则很简单，但取决于具体情形。信息性图片需要对其含义（而非外观）做简明描述。不增添任何信息的装饰性图片应带有空的 alt=""，让屏幕阅读器跳过它们。功能性图片——充当按钮的图标——必须描述动作，而非图像本身。诸如图表之类的复杂视觉内容需要一段简短的 alt，外加在附近提供更长的文本等价物。

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

自动化工具能立即捕捉到替代文本的缺失。它们无法告诉你文本是否正确——那需要由人来在上下文中阅读页面。

颜色对比度不足

影响哪些人： 低视力、色盲或与年龄相关的视力衰退人士；任何在强烈阳光下使用屏幕的人。

WCAG 标准： 1.4.3 对比度（最低），AA 级；另加针对 UI 组件的 1.4.11 非文本对比度。

WCAG 2.2 要求普通文本的对比度至少为 4.5:1，大号文本至少为 3:1（大约 18pt，或 14pt 加粗）。界面组件和有意义的图形——输入框边框、焦点指示器、传达状态的图标——相对于其周围环境必须达到 3:1。对比度问题是每一次大规模审计中最常见的问题之一，而且几乎总是在设计阶段被引入。

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

测试整套配色，而不只是正文：占位符文本、仍需被读到的禁用状态、错误信息，以及叠加在照片之上的文本，都是常见的违规者。切勿仅依赖颜色来传达含义（1.4.1）——无效字段上的红色边框必须搭配文本或图标。

自动播放的媒体与动效

影响哪些人： 患有前庭功能障碍、注意力或认知障碍的人士、音频输出被淹没的屏幕阅读器用户，以及任何身处安静共享空间的人。

WCAG 标准： 1.4.2 音频控制（A 级）、2.2.2 暂停、停止、隐藏（A 级）、2.3.1 三次闪烁（A 级），以及 2.3.3 来自交互的动画（AAA 级）。

自动播放超过三秒的音频或视频，必须提供一种明显的暂停或静音方式。持续超过五秒的移动、闪烁或自动更新的内容——轮播、动画横幅、跑马灯——需要一个无障碍的暂停控件。每秒闪烁超过三次的内容可能诱发癫痫发作，必须完全避免。尊重用户的 prefers-reduced-motion 设置，以减弱非必要的动画。

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

可操作：人们无法使用的部分

键盘不可访问与键盘陷阱

影响哪些人： 无法使用鼠标的运动障碍人士、屏幕阅读器用户（通过键盘导航），以及使用切换设备或语音控制的人。

WCAG 标准： 2.1.1 键盘（A 级）和 2.1.2 无键盘陷阱（A 级）。

每一项交互——链接、按钮、表单字段、菜单、模态框、日期选择器、拖放——都必须仅用键盘即可完全操作。最具破坏性的变体是键盘陷阱：焦点进入某个组件（通常是模态框或嵌入式控件）后无法退出，使用户被困在页面上。自定义构建的控件是常见的元凶，因为像 <button> 和 <a> 这样的原生元素默认就支持键盘操作，而基于 <div> 的仿制品则不然。

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

仅使用 Tab、Shift+Tab、方向键、Enter、空格键和 Escape 走一遍你的关键流程。确认焦点始终能够在每个组件中向前移动并退出，Escape 能关闭浮层，且没有任何环节需要指针。我们的 屏幕阅读器评估 服务正是按照真实辅助技术用户的体验方式来测试这些流程。

缺失或不可见的焦点指示器以及不合逻辑的焦点顺序

影响哪些人： 有视力的键盘用户、低视力用户，以及任何在页面上迷失了当前位置的人。

WCAG 标准： 2.4.7 焦点可见（A 级）和 2.4.3 焦点顺序（A 级）；WCAG 2.2 中的 2.4.11 焦点不被遮挡（AA 级）。

一个常见的“整洁化”错误是用 outline: none 移除浏览器默认的焦点环，却从不替换它。键盘用户由此无从知道哪个元素处于活动状态。同样有害的是不遵循视觉和逻辑阅读顺序的焦点顺序——通常由正的 tabindex 值，或与渲染布局相背离的 DOM 顺序所导致。

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 新增了 2.4.11：当某个元素获得焦点时，它不得被固定页眉、Cookie 横幅或聊天控件完全遮挡。打开一个模态框，用 Tab 键穿行其中，确认获得焦点的元素从不会被埋没。

缺乏描述性的链接和按钮

影响哪些人： 调出全部链接列表来快速浏览页面的屏幕阅读器用户，以及认知障碍人士。

WCAG 标准： 2.4.4 链接目的（在上下文中），A 级；2.5.3 名称中的标签，A 级。

屏幕阅读器用户常常通过在脱离上下文的链接之间跳转来导航。当一个充满“点击这里”“阅读更多”和“了解更多”链接的页面被当作列表读出时，就变得毫无意义。链接文本应能独立描述其目标。这同样适用于仅含图标的按钮，它们需要一个无障碍名称。

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

导航过于臃肿且无法跳过

影响哪些人： 屏幕阅读器用户、键盘用户，以及认知障碍人士。

WCAG 标准： 2.4.1 绕过区块（A 级）。

一个包含数十个链接的大型菜单，会迫使屏幕阅读器和键盘用户在每个页面上都先趟过整份列表才能抵达内容。把“跳至主内容”链接作为第一个可获得焦点的元素，能让他们直接越过重复的区块。将相关项分组、保持菜单精简，并确保跳转链接在获得焦点时变为可见。

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

可理解：令人困惑的内容

未标注或关联不当的表单字段

影响哪些人： 屏幕阅读器用户、认知障碍人士，以及按名称调用字段的语音控制用户。

WCAG 标准： 1.3.1 信息与关系、3.3.2 标签或说明，以及 4.1.2 名称、角色、值（均为 A 级）。

没有以程序方式关联 <label> 的输入框会被朗读为“编辑文本，空白”——用户根本不知道该输入什么。占位符文本不能替代标签：它在输入时会消失，而且通常对比度不达标。必填字段、格式规则和验证错误也必须以文本传达，而不能仅靠颜色或位置。

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

用 aria-describedby 将错误信息与其字段关联起来，用 aria-invalid 标记无效字段，并确保提交不完整的表单时焦点会移到第一个错误处。

缺失页面语言

影响哪些人： 屏幕阅读器用户——错误的语言会导致合成器把所有内容都读错音。

WCAG 标准： 3.1.1 页面语言（A 级）和 3.1.2 部分内容的语言（AA 级）。

仅仅一个缺失的属性就会破坏整个页面的发音。在根元素上声明主要语言，并用各自的 lang 标记另一种语言的内联段落。

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

标题层级不当与缺失地标

影响哪些人： 通过标题和区域导航的屏幕阅读器用户，以及任何依赖文档结构的人。

WCAG 标准： 1.3.1 信息与关系（A 级）。

标题是页面的大纲。屏幕阅读器用户通过在标题间跳转来快速找到内容；当层级被跳过、纯粹为了字号而使用，或干脆缺失时，这种导航就会崩溃。每个页面应有一个 <h1>，以及一个合乎逻辑、不间断的 <h2>、<h3> 等序列。同样重要的是地标区域——<header>、<nav>、<main>、<footer>——它们让用户能在各主要区域之间跳转。一个完全由 <div> 元素构建的页面则提供不了这样一张地图。

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

健壮：辅助技术无法解析的代码

不可访问的自定义控件与误用的 ARIA

影响哪些人： 首当其冲的是屏幕阅读器用户，以及任何依赖正确无障碍树的辅助技术。

WCAG 标准： 4.1.2 名称、角色、值（A 级）。

由 <div> 和 <span> 构建的自定义下拉框、标签页、手风琴、组合框、模态框和工具提示，本身并不具备角色、状态或键盘行为。开发人员会借助 ARIA 来打补丁，但 ARIA 只是描述——它不增加任何行为，而错误的 ARIA 比没有更糟。ARIA 的第一条规则是：只要存在原生 HTML 元素，就优先使用它。当你不得不构建自定义控件时，请实现 ARIA 创作模式所规定的完整键盘交互，并让 aria-expanded、aria-selected 等状态与实际情况保持同步。

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

这些恰恰是自动化扫描器最常遗漏的问题。扫描器看到一个 aria-expanded 属性便让它通过；只有人（或使用屏幕阅读器的测试者）才能确认当菜单打开时该值是否真的发生了翻转。请参阅我们的 屏幕阅读器测试指南，了解如何端到端地验证控件行为。

关于叠加层控件的说明

人们很容易想去安装一行式的“无障碍控件”或叠加层，它承诺即时合规。这些工具并不能修复上述问题——替代文本在源码中依然缺失，对比度依然不达标，自定义控件依然失灵。叠加层无法修正导致障碍的代码，它们还经常干扰用户自己的辅助技术，并且已经出现在越来越多的无障碍诉讼中。真正的 数字无障碍 来自于修复底层的 HTML、CSS 和行为，而不是去掩盖它们。

阻止这些问题卷土重来

把一份缺陷清单修复一次是必要的，但并不充分；除非你改变交付方式，否则相同的问题会在下一次发布时再次出现。持久的解决之道，是把无障碍构建进工作流程：

如需一份循序渐进的整改路线图，请从我们关于 如何让你的网站符合 WCAG 的指南开始。

今天从何处着手

全球有超过 13 亿人正与某种形式的残障共处，无障碍的商业理由显而易见——而自 2025 年 6 月起，依据 European Accessibility Act 的法律理由同样如此。本目录中的问题，正是任何投诉或审计中最先被审视的那些。

要了解自己当前所处的状况，最快的方式是运行一次 免费的 URL 扫描——无需设置，毫无义务。当你准备好超越自动化所能触及的范围时，预约演示，我们将向你展示一套自动化加人工相结合的方案如何弥合余下的差距。

找出自动化工具遗漏的问题

咨询专家 免费无障碍扫描