Skip to main content

可访问性设计：让每个人都能使用的设计

你有没有过这样的经历？

  • 走在街上，太阳很大，手机屏幕完全看不清
  • 鼠标坏了，只能用键盘操作，结果很多按钮都点不到
  • 晚上刷手机，屏幕太亮，晃得眼睛疼
  • 看视频没字幕，周围很吵，完全听不到在说什么

如果有，那你已经体验过"可访问性问题"了。

很多人觉得"可访问性"是给"残疾人"做的，和自己没关系。 但实际上，可访问性是给所有人的。

  • 年轻人视力好，但在阳光下也看不清屏幕
  • 正常人手脚利索，但拎着东西的时候，也只能单手操作
  • 听力正常的人，在嘈杂的环境里也听不清视频
  • 专注力好的人，累的时候也容易分心

可访问性（Accessibility，简称 a11y），不是"为少数人做的额外功能"，而是"好设计的基本要求"。

这篇文章，我们聊聊可访问性设计的核心原则和实践方法。

为什么可访问性很重要？​

在讲怎么做之前，我们先搞清楚：为什么要做可访问性？

这是正确的事​

从最朴素的角度说——每个人都应该能平等地获取信息和服务。

互联网的初衷，就是让信息自由流动。 如果你的网站/APP 只有"正常人"能用，那你就把一部分人挡在了门外。

  • 视障用户：看不见，靠屏幕阅读器
  • 听障用户：听不见，靠字幕和文字
  • 运动障碍：手不方便，靠键盘或辅助设备
  • 认知障碍：理解困难，需要更简单的设计

这些人，也是你的用户。 他们也应该能正常地使用你的产品。

用户比你想象的多​

"残障人士很少吧？应该没几个用户。"

错了。

根据世界卫生组织的数据，全球大约有 15 亿人 有某种形式的残障——占总人口的 15%。

这不是一个小数目。

而且，这还没算上"临时性残障"和"情境性残障"：

  • 胳膊摔断了 → 临时性运动障碍
  • 太阳底下看不清屏幕 → 情境性视觉障碍
  • 周围很吵听不清 → 情境性听觉障碍
  • 刚生完孩子很疲劳 → 情境性认知障碍

算上这些，几乎每个人在人生的某个阶段，都会遇到可访问性的问题。

所以，做可访问性，不只是帮"别人"，也是帮未来的你自己。

这是法律要求​

越来越多的国家和地区，已经把可访问性写入了法律。

  • 美国：ADA（美国残疾人法案）
  • 欧盟：EN 301 549 标准
  • 中国：《信息无障碍标准》

如果你的产品不符合可访问性标准，可能会面临法律诉讼和罚款。

而且，越来越多的政府项目、企业采购，都把可访问性作为硬性要求。 不做可访问性，你可能连投标的资格都没有。

好的可访问性 = 好的用户体验​

这是最重要的一点：可访问性做得好的产品，对所有人都更好用。

  • 字幕不只是给聋人看的——正常人在嘈杂环境里也会用
  • 高对比度不只是给弱视的——在阳光下也更好看
  • 键盘操作不只是给行动不便的——程序员就喜欢用键盘
  • 清晰的结构不只是给屏幕阅读器的——所有人都更容易理解

可访问性不是"锦上添花"，而是"基础体验"。 它不是为了少数人牺牲多数人的体验——它是提升所有人的体验。

可访问性的核心原则​

WCAG无障碍标准：Web内容无障碍指南的四大原则与合规等级

可访问性的标准很多，但核心原则其实很简单。

WCAG（Web 内容无障碍指南）把它总结为四个原则：POUR。

P = Perceivable 可感知​

信息必须是用户能够感知到的。

什么意思？

  • 不能只有视觉信息，盲人看不到
  • 不能只有听觉信息，聋人听不到
  • 不能只有颜色区分，色盲分不清

怎么做到？

  • 图片要有替代文字（alt 文本）
  • 视频要有字幕
  • 音频要有文字稿
  • 不要只用颜色传递信息（还要有形状、文字、图标）
  • 内容要有足够的对比度

O = Operable 可操作​

用户必须能够操作界面。

什么意思？

  • 不能只用鼠标，键盘也能操作
  • 不能操作太快，用户跟不上
  • 不能有容易触发误操作的设计

怎么做到？

  • 所有功能都支持键盘操作
  • 有足够大的点击区域（至少 44x44px）
  • 给用户足够的时间完成操作
  • 避免闪烁的内容（可能引发癫痫）
  • 支持撤销和纠错

U = Understandable 可理解​

内容和操作必须是用户能够理解的。

什么意思？

  • 文字要清晰易懂
  • 操作要符合预期
  • 出错了要告诉用户怎么改

怎么做到？

  • 语言要简单、清晰
  • 页面结构要一致、可预测
  • 表单要有明确的标签和提示
  • 出错了要有明确的错误提示和解决方法
  • 帮助信息要容易找到

R = Robust 健壮性​

内容必须足够健壮，能在各种环境下使用。

什么意思？

  • 不同的浏览器、不同的设备、不同的辅助技术，都能正常用
  • 代码要规范，要符合标准

怎么做到？

  • 用标准的 HTML 标签
  • 正确使用语义化标签
  • 测试各种辅助技术（屏幕阅读器、放大镜等）
  • 遵循 W3C 标准

这四个原则，是可访问性的基石。 所有的具体规范，都是从这四个原则衍生出来的。

视觉可访问性​

先从最直观的——视觉可访问性，开始讲。

颜色对比度​

这是最常见，也最容易被忽略的问题。

很多设计师喜欢用浅灰色的文字——"高级"、"有气质"。 但浅灰色的文字，对比度不够，很多人看不清。

WCAG 的对比度标准：

  • AA 级（基本要求）
    • 正文文字：对比度 ≥ 4.5:1
    • 大字号文字（≥ 18pt 或 ≥ 14pt 粗体）：对比度 ≥ 3:1
    • UI 组件（按钮边框、图标等）：对比度 ≥ 3:1
  • AAA 级（更高要求）
    • 正文文字：对比度 ≥ 7:1
    • 大字号文字：对比度 ≥ 4.5:1

一般来说，做到 AA 级就可以了。 AAA 级是更高追求，但不是必须的。

常见误区：

  • "我觉得能看清啊" → 你的视力可能比大多数人好
  • "设计感最重要" → 看都看不清，谈什么设计感
  • "灰色文字不影响" → 影响大了，很多人真的看不清

怎么检查对比度？

  • 工具：WebAIM Contrast Checker、Contrast、Figma 插件（A11y - Color Contrast Checker）
  • 简单方法：眯起眼睛看，看不清就是对比度不够

不要只用颜色传递信息​

"红色是错误，绿色是成功，黄色是警告"——很多设计里，颜色是唯一的区分方式。

但红绿色盲的用户，根本分不清。

世界上大约 8% 的男性是红绿色盲（女性很少）。 也就是说，每 12 个男性里，就有一个人分不清红和绿。

正确做法： 不要只用颜色，还要加上——

  • 图标（错误加个叉，成功加个勾）
  • 文字（明确写"错误"、"成功"）
  • 形状（不同的形状、不同的线条样式）

例子：

  • ❌ 坏例子：表单错误输入框只有红色边框
  • ✅ 好例子：红色边框 + 红色的叉图标 + 错误文字提示

色盲友好设计​

除了"不用颜色传递信息"，还有一些色盲友好的设计技巧。

1. 安全的配色方案 有些颜色组合，色盲用户是分不清的：

  • 红 + 绿（最常见）
  • 蓝 + 紫
  • 绿 + 棕

如果必须用多种颜色区分，尽量选择色盲用户也能分清的组合。

工具：

  • Coblis：模拟色盲视角
  • Color Safe：色盲友好的配色工具
  • Figma 插件：Color Blind

2. 纹理和图案 除了颜色，还可以用不同的纹理、图案、形状来区分。 比如图表里，不同的系列用不同的填充图案（条纹、点阵、斜纹……）。

3. 直接标注 如果是图表，直接在数据旁边标上文字标签。 不用用户去"对颜色看图例"。

文字的可读性​

除了颜色对比，文字本身的可读性也很重要。

1. 字号不要太小

  • 正文最小 16px
  • 小字体（注释、说明）至少 12px
  • 可以支持用户放大字号（浏览器的字号调整）

2. 行高要合适

  • 正文行高 1.5-1.8 倍
  • 行高太小，容易串行
  • 行高太大，读着累

3. 字体要清晰

  • 不要用太细的字体（细体在屏幕上可能看不清）
  • 不要用太花哨的字体做正文
  • 优先选择易读性好的无衬线体

4. 不要用全大写的长文本

  • 全大写的英文很难读
  • 中文同理，不要全部加粗或全部用特大字号

放大和缩放​

很多视力不好的用户，会把浏览器的字号放大，或者用屏幕放大镜。

你的设计要支持：

  • 字号放大到 200%，页面还能用（不会溢出、不会重叠）
  • 屏幕放大后，内容还是清晰的（用矢量图、高清图）
  • 不要固定死像素大小，尽量用相对单位（rem、em）

响应式设计 本质上也是可访问性的一部分—— 它让不同尺寸的设备、不同缩放比例的用户，都能正常使用。

交互可访问性​

色彩对比度与无障碍设计：WCAG对比度标准与色盲友好配色方案

看完了视觉的，我们来看看交互的。

键盘可访问性​

键盘操作是可访问性的基石。 很多用户不用鼠标——

  • 视障用户用屏幕阅读器，主要靠键盘
  • 运动障碍用户可能用键盘或其他辅助设备
  • 很多程序员、效率用户，也喜欢用键盘操作

键盘可访问性的基本要求：

1. 所有可交互元素都能用 Tab 键聚焦

  • 按钮、链接、输入框、下拉菜单……
  • 不能有只能用鼠标点的功能

2. 焦点状态清晰可见

  • 用户用 Tab 键移动焦点的时候，要能清楚地看到当前焦点在哪里
  • 不要把默认的 focus 样式去掉（很多人觉得丑就删了，这是不对的）
  • 如果觉得默认样式丑，可以自定义，但一定要有

3. 操作符合预期

  • Tab 键的顺序要符合视觉顺序（从左到右，从上到下）
  • Enter 键可以触发按钮和链接
  • 空格键可以触发复选框、单选框
  • Esc 键可以关闭弹窗、菜单
  • 方向键可以导航下拉菜单、标签页

4. 键盘陷阱

  • 不能把用户的键盘焦点"困"在某个地方
  • 比如打开弹窗，焦点进去了，但出不来
  • 正确做法：打开弹窗，焦点移进去；按 Esc，关闭弹窗，焦点回到原来的位置

怎么测试键盘可访问性？ 很简单——把鼠标放一边，只用键盘操作一遍。

  • Tab：移动焦点
  • Enter / Space：触发
  • Esc：取消/关闭
  • 方向键：导航

如果你自己都用不下去，那键盘可访问性肯定有问题。

点击区域大小​

"按钮太小了，点不准"——这是很多人都遇到过的问题。

对于手指操作的移动端，这个问题更严重。

推荐的最小点击区域：

  • 移动端：至少 44x44px（苹果 HIG）、48x48px（安卓 Material Design）
  • 桌面端：至少 24x24px，推荐 32x32px 以上

常见问题：

  • 图标按钮太小了
  • 文字链接只有文字能点，周围空白不能点
  • 按钮挨得太近，容易误触

解决方法：

  • 给小图标加 padding，扩大点击区域
  • 链接的点击区域要包含周围的空白
  • 按钮之间留足够的间距

动效与动画​

动效不是不能做，但要考虑可访问性。

1. 避免闪烁和频闪

  • 每秒闪烁 3 次以上的内容，可能引发癫痫发作
  • 特别是红闪，风险更高
  • 绝对不要做快速闪烁的效果

2. 支持减少动效

  • 有些用户（比如前庭功能障碍的人）看动效会头晕、恶心
  • 操作系统里有"减少动态效果"的选项
  • 你的产品应该尊重这个设置

技术实现：

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

3. 动效不要干扰阅读

  • 自动播放的视频、轮播图、滚动动画……
  • 这些会分散注意力，影响阅读
  • 最好给用户控制权，可以暂停、可以关闭

表单可访问性​

表单是用户和产品交互的重要方式，也是可访问性问题的重灾区。

常见的表单问题：

  • 输入框没有标签（只有 placeholder）
  • 错误提示不明确
  • 必填项没有标记
  • 键盘操作不友好

好的表单应该：

1. 每个输入框都有明确的标签（label）

  • 不要只用 placeholder 当标签（用户一输入就没了）
  • 标签和输入框要关联起来（用 <label> 标签）
  • 标签位置要清晰，不要到处飘

2. 明确的必填标记

  • 必填项用星号（*）标记
  • 或者用文字说明"以下为必填项"
  • 不要等用户提交了才告诉他哪些必填

3. 清晰的错误提示

  • 错误提示要告诉用户"哪里错了"、"为什么错"、"怎么改"
  • 错误提示要靠近出错的输入框
  • 不要只说"输入有误"，要说"请输入正确的邮箱格式"

4. 输入提示和帮助

  • 复杂的输入格式，提前给提示
  • 比如密码要求："至少 8 位，包含字母和数字"
  • 不要等用户输错了再告诉他

5. 支持自动填充

  • 手机号、邮箱、地址……
  • 支持浏览器自动填充，减少用户输入

内容可访问性​

可访问性不只是设计和技术的事，内容也是。

语义化结构​

很多人做页面，全是 <div> + <span>，全靠 CSS 来表现。 这样视觉上可能没问题，但屏幕阅读器根本读不懂。

正确做法：用语义化的 HTML 标签。

  • <h1> - <h6>：标题层级
  • <p>：段落
  • <ul> / <ol> / <li>：列表
  • <button>：按钮
  • <a>：链接
  • <nav>：导航
  • <main>：主要内容
  • <header>：页眉
  • <footer>：页脚
  • <section>：章节
  • <article>：文章
  • <aside>：侧边栏

为什么语义化重要？

  • 屏幕阅读器可以根据标签，告诉用户"这是标题"、"这是列表"
  • 用户可以快速跳转（比如"跳到下一个标题"）
  • 搜索引擎也能更好地理解内容

结构清晰的内容，对所有人都更好——

  • 视障用户能用屏幕阅读器听懂
  • 正常用户扫一眼标题也能快速理解

替代文本（Alt Text）​

图片不能只是"好看"——还要能被"读"出来。

什么是替代文本？ 就是图片的文字描述，放在 alt 属性里。 屏幕阅读器读到图片的时候，会把 alt 文本读出来。

Alt 文本怎么写？

1. 内容图片（有实际意义的图）

  • 要准确描述图片的内容和作用
  • 要简洁，不要太长（一般 100 字以内）
  • 不要以"图片的"、"照片的"开头（屏幕阅读器会自动说"图片"）

例子：

  • ❌ 坏例子：alt="图片"
  • ❌ 坏例子：alt="产品图"
  • ✅ 好例子：alt="2024 年新款手机，正面全屏，背面三摄"

2. 装饰性图片（纯装饰，没有实际意义）

  • alt 留空：alt=""
  • 这样屏幕阅读器会直接跳过它
  • 不要写"装饰图"、"分隔线"之类的，没用

3. 功能图片（按钮、图标）

  • 描述它的功能，而不是外观
  • 比如：搜索图标 → alt="搜索"，而不是 alt="放大镜"

Alt 文本看起来简单，但很多人都写不好。 写的时候，想象一下——"如果我看不到这张图，我想知道什么？"

视频与音频的可访问性​

视频和音频，也要考虑可访问性。

视频：

  • 字幕：必须有（给听障用户，也给嘈杂环境下的用户）
  • 字幕：不只是对话，还要有重要的声音提示（比如"敲门声"、"音乐响起"）
  • 手语翻译：如果预算允许，可以加手语小窗口
  • 文字稿：提供完整的文字版本，方便快速浏览

音频（播客等）：

  • 提供文字稿
  • 节目简介要写清楚内容概要

语言与可读性​

内容本身也要易于理解。

1. 语言要简单清晰

  • 不要用太专业的术语（除非用户都是专业人士）
  • 句子不要太长
  • 段落不要太大
  • 用用户听得懂的话，不要自说自话

2. 结构要清晰

  • 有明确的标题层级
  • 重要的内容放在前面
  • 用列表、加粗等方式突出重点
  • 大段文字拆成小段

3. 链接文字要有意义

  • ❌ 坏例子："点击这里"、"了解更多"、"详情"
  • ✅ 好例子："查看用户协议"、"下载设计规范"

为什么？因为屏幕阅读器用户会"跳着读链接"—— 如果所有链接都是"点击这里"，他根本不知道每个链接是干嘛的。

技术实现要点​

屏幕阅读器与ARIA标签：语义化HTML与无障碍开发最佳实践

可访问性不只是设计师的事，也是工程师的事。

这里简单提几个技术要点（给前端同学看的）。

语义化 HTML​

前面已经说了，用语义化标签。 这是最简单，也是性价比最高的可访问性优化。

ARIA 标签​

有些复杂的组件，原生 HTML 标签不够用—— 比如 tab 切换、模态框、下拉菜单……

这时候可以用 ARIA（Accessible Rich Internet Applications） 来补充语义。

常用的 ARIA 属性：

  • role：定义元素的角色（比如 role="tab"、role="dialog"）
  • aria-label：给元素加一个文字标签
  • aria-hidden：对屏幕阅读器隐藏元素
  • aria-expanded：表示展开/收起状态
  • aria-current：表示当前选中项
  • aria-live：动态内容变化时，通知屏幕阅读器

注意： ARIA 是用来"补充"语义的，不是用来"替代"语义的。

  • 能用原生 <button>，就不要用 <div role="button">
  • 能用原生 <a>，就不要用 <span role="link">

原生标签自带的可访问性支持是最好的。

焦点管理​

复杂的交互组件，需要手动管理焦点。

常见场景：

  • 打开弹窗：焦点移到弹窗内
  • 关闭弹窗：焦点回到触发弹窗的按钮
  • 下拉菜单：用方向键导航选项
  • 标签页：用左右方向键切换标签

焦点管理做得好，键盘用户才能流畅地使用你的产品。

测试工具​

可访问性可以用工具来辅助检查。

自动化工具：

  • axe DevTools：浏览器插件，可以扫描页面的可访问性问题
  • WAVE：另一个浏览器插件
  • Lighthouse：Chrome 自带的，里面有可访问性评分

注意： 自动化工具只能发现 30% 左右的可访问性问题。 剩下的问题，需要人工测试。

人工测试：

  • 键盘测试：只用 Tab、Enter、Esc 操作一遍
  • 屏幕阅读器测试：用 VoiceOver（Mac）、NVDA（Windows）、TalkBack（安卓）
  • 缩放测试：把字号放大 200%，看看会不会乱
  • 色盲测试：用色盲模拟工具看一下

可访问性设计清单​

最后，给大家一个简单的检查清单。 设计完之后，对着过一遍。

视觉​

  • 正文文字对比度 ≥ 4.5:1
  • 大文字对比度 ≥ 3:1
  • 不只用颜色传递信息（还有图标/文字/形状）
  • 字号不小于 16px
  • 行高合适（正文 1.5-1.8 倍）
  • 支持字号放大到 200%

交互​

  • 所有功能都能用键盘操作
  • 焦点状态清晰可见
  • Tab 顺序符合视觉顺序
  • 点击区域至少 44x44px（移动端）
  • 没有键盘陷阱
  • 支持减少动效
  • 没有快速闪烁的内容

表单​

  • 每个输入框都有 label
  • 必填项有明确标记
  • 错误提示清晰（哪里错了、怎么改）
  • 输入格式有提前提示
  • 支持自动填充

内容​

  • 图片有合适的 alt 文本
  • 页面结构语义化（标题、列表……）
  • 标题层级正确（不要跳级）
  • 链接文字有意义（不是"点击这里"）
  • 视频有字幕
  • 语言清晰易懂

技术​

  • 用语义化 HTML 标签
  • 正确使用 ARIA
  • 动态内容有 aria-live 通知
  • 弹窗、菜单等组件焦点管理正确

常见误区​

辅助技术与包容性设计：从键盘导航到屏幕阅读器的全场景无障碍体验

最后，说说可访问性的几个常见误区。

误区一：可访问性是给残疾人用的​

错。

前面已经说了，可访问性是给所有人的。

  • 阳光下看不清屏幕的你
  • 拎着东西只能单手操作的你
  • 嘈杂环境里听不清视频的你
  • 年纪大了视力下降的你

可访问性 = 好的设计。 它不是"额外功能"，而是"基础体验"。

误区二：可访问性很丑​

很多人觉得—— "可访问性就是要高对比度、大按钮、丑丑的" "做了可访问性，设计就不高级了"

错。

可访问性和好看不矛盾。

  • 高对比度也可以很好看
  • 大按钮也可以很精致
  • 很多优秀的设计，可访问性做得非常好

不好的设计，才会把可访问性做成"丑"的样子。 好的设计师，可以做到既好看，又好用。

误区三：可访问性成本很高​

很多团队觉得—— "可访问性好麻烦，要花很多时间" "我们现在没精力做这个"

错。

可访问性不是"最后再加"的东西—— 而是从一开始就要考虑的东西。

  • 设计的时候，顺手把对比度调对
  • 写代码的时候，顺手写语义化标签
  • 做组件的时候，顺手把键盘操作加上

如果从一开始就做，成本其实很低。 最怕的是——做完了才想起要做可访问性，那时候改起来成本就高了。

而且，可访问性的投入，回报是很高的——

  • 覆盖更多用户
  • 提升整体用户体验
  • 避免法律风险
  • 建立品牌的正面形象

这笔账，怎么算都是划算的。

误区四：我们没有残障用户​

"我们的产品用户都是年轻人，没有残疾人，不用做。"

首先，你确定吗？

  • 15% 的人有某种形式的残障，这是全球平均水平
  • 你的用户里，很可能就有

其次，就算真的没有（不太可能），可访问性对普通用户也是有好处的。

  • 阳光下看得清了
  • 键盘操作更方便了
  • 内容结构更清晰了

这些都是实实在在的体验提升。

可访问性不是"慈善"，而是"投资"。

写在最后​

可访问性到底是什么？

我觉得，它是一种同理心。

做设计的时候，不要只想着"我觉得好不好看"—— 还要想一想：

  • 如果我看不见，这个产品能用吗？
  • 如果我听不见，这个产品能用吗？
  • 如果我手脚不方便，这个产品能用吗？
  • 如果我年纪大了，这个产品能用吗？

把自己放到不同用户的处境里，去感受、去思考。

这就是同理心。

好的设计，不是让"正常人"用得爽。 好的设计，是让所有人都能用，都能用得舒服。

这不是什么"高尚的道德"—— 这是设计最基本的责任。

毕竟，我们每个人，都有可能在人生的某个时刻，成为那个"需要帮助的人"。

今天你为别人多考虑一分， 明天别人也会为你多考虑一分。

这就是可访问性的意义。