Emoji 无障碍设计:7 个屏幕阅读器与包容性设计模式

世界卫生组织估计,全球有 16% 的人口存在某种形式的残障;在大多数国家,残障率最高的互联网用户群体是 50 岁以上人群。对 emoji 使用来说,这一点的含义一点也不微妙:你相当一部分受众看不到你发的 emoji。对他们而言,emoji 是音频 ， 由屏幕阅读器朗读出来 ， 或者完全不存在。下面的 7 个模式就是让 emoji 真正对所有人都能用。

屏幕阅读器实际是怎么读 emoji 的

不同屏幕阅读器(NVDA、JAWS、VoiceOver、TalkBack)对 emoji 的处理方式不同。差异集中在三个方面:哪些 emoji 会被朗读出来(部分默认是静音的)、朗读时用什么名称(CLDR 短名、平台显示名、还是自定义覆盖),以及多码点序列如何处理(ZWJ 序列要么按名称序列读出、要么按单一名称读出,取决于平台)。

差异是显著的。NVDA 把 ZWJ 序列读成一串 emoji 名称加上字面短语 "zero width joiner",轻则烦人、重则让人困惑。JAWS 把同样的序列读成一个组合名称,比如 "family man woman girl"。同样的输入产生非常不同的音频输出。这就是为什么要测试。

规范名称的角色

CLDR 短名是大多数屏幕阅读器默认朗读的内容。💀 的 CLDR 短名是 Skull(头骨)。大多数英语 emoji 用法里的口语化名称是 "I am dead"(我死了)或 "dead"(死)。屏幕阅读器用户在听到 "I just got tickets 💀" 这条消息时,听到的是 "I just got tickets, skull"(我刚刚拿到票了,头骨)。规范名称和想表达的含义不匹配,这是 emoji 使用中最大的无障碍缺口之一。

修法是把 emoji 包在一个能反映想表达含义的标签里。HTML 中最可靠的做法是使用带 role="img" 与 aria-label 属性的 span 元素。屏幕阅读器就会朗读 aria-label、而不是规范名称。视觉渲染不变。

模式 1:选用规范名称良好的 emoji

有些 emoji 的规范名称和口语用法一致。🔥 在 CLDR 里是 Fire(火焰),用户发它时想表达的也是这个意思。💀 的规范名是 Skull(头骨),接近口语的 "I am dead" 但不完全相同。🫠 的规范名是 Melting Face(融化的脸),远远不是口语的 "this is overwhelming"(这太让人抓狂了)。当规范名接近想表达的含义时,就不需要额外的无障碍处理。

模式:当为标签、按钮、图标选择 emoji 时,优先选用 CLDR 名称与意图一致的 emoji。避免使用名称技术化或模糊的 emoji("Sparkles" 没问题,"Circle Compass" 就比较难解读)。

模式 2:把装饰性 emoji 包在 aria-hidden 中

装饰性 emoji ， 那些只增加视觉点缀、不承载含义的 emoji ， 不应该被屏幕阅读器读出来。Web 标准做法是使用 aria-hidden="true" 属性。

示例:<span aria-hidden="true">🎉</span>。视觉渲染不变。屏幕阅读器完全跳过这个 emoji。任何纯粹装饰性的 emoji ， "恭喜"消息旁的彩带、按钮旁的星标、页眉里的笑脸 ， 都应该用这种模式。

模式 3:在 emoji-as-text 场景使用 role="img" + aria-label 模式

当一个 emoji 承担语义工作 ， 它是标签、图标,或消息中有意义的一部分 ， 就把它包在带 role="img" 的 span 里,aria-label 写上你想表达的含义。

示例:<span role="img" aria-label="new">✨</span>。屏幕阅读器朗读 aria-label("new"),而不是 CLDR 短名("Sparkles")。视觉渲染不变。任何 emoji-as-text 场景,包括图标标签、状态指示、用 emoji 替代文字,都应该用这种模式。

模式 4:避免对肤色的预设

肤色修饰符(U+1F3FB 到 U+1F3FF)属于 emoji 编码的一部分,但屏幕阅读器默认不会朗读它们。一条带 👋🏿(挥手、深色肤色)的消息在 NVDA 里被读成 "waving hand"(挥手)， 肤色不会被读出。这是 Unicode 联盟的一项刻意设计(读出肤色反而会显得简化),但对包容性设计有影响。

模式:不要假设默认的黄色 emoji 对所有用户都是正确的选择。黄色 emoji 是一种刻意的中立,但对有色人种用户来说可能读起来像"这不属于我"。当肤色在语境中合适时,使用修饰符;不合适时,默认用中性黄色。

模式 5:为纯 emoji 内容提供文字替代

一条 100% 由 emoji 组成的消息 ， 在 Snapchat、TikTok、Instagram DM 中很常见 ， 对屏幕阅读器用户是不可见的,除非提供文字替代。Web 标准里图片用 alt 属性,emoji 最接近的等价物是提供一段视觉上隐藏的文字替代。

模式:当一条消息或标签是纯 emoji 时,在它后面跟一段视觉上隐藏的文字,让屏幕阅读器朗读出来。最常见的实现方式是 sr-only 工具类。示例:<span class="sr-only">新消息</span> <span aria-hidden="true">💌</span>。屏幕阅读器朗读文字,视觉上看到的只是 emoji。任何需要无障碍的纯 emoji 标签、按钮、消息都该用这种模式。

模式 6:尊重用户的 emoji 偏好

有些用户会彻底关闭 emoji 渲染,要么通过无障碍设置(Android 有"移除所有 emoji"的开发者选项),要么通过自定义 CSS(text-rendering: none)。当 emoji 被关闭后,底层的码点仍会以文字或方框的形式出现,具体取决于平台。

模式:不要假设 emoji 一定会渲染。如果一条消息是纯 emoji、而 emoji 渲染被关掉了,接收方看到的就是一串方框或字面文字 "U+1F602"。正确的应对是提供不依赖 emoji 渲染的文字替代。这和模式 5 是同一种 ， 屏幕阅读器或纯文字浏览器可以朗读的隐藏文字。

模式 7:用真实的屏幕阅读器测试

上面 6 个模式只是起点、不是保证。要想真正知道你的 emoji 在屏幕阅读器里听起来是什么样,唯一的方法是用你的用户实际使用的屏幕阅读器去测。Windows 上的 NVDA(免费)、macOS 与 iOS 上的 VoiceOver(自带)、Android 上的 TalkBack(自带)是必测的三个。三者对 emoji 的处理方式各不相同,各自有各自的怪癖。

测试方法:打开屏幕阅读器,导航到那个页面,听它朗读什么。如果朗读内容与想表达的含义不匹配,加上 aria-label。如果朗读出来的是字面的 CLDR 短名、而实际想用的是俚语,加上自定义标签。反复迭代,直到音频输出与视觉输出一致。

实战示例:"new"徽章

一个常见的 emoji-as-label 场景是 "new" 徽章 ， 那个出现在刚上线功能旁边的 ✨。✨ 的 CLDR 短名是 Sparkles(闪光),并不是这个徽章想表达的意思。一个屏幕阅读器用户在浏览到这个徽章时听到的是 "sparkles"(闪光)而不是 "new"(新),这条朗读信息对这个功能来说毫无价值。

同一个徽章的无障碍版本在 HTML 里长这样:<span role="img" aria-label="new">✨</span>。屏幕阅读器朗读 "new"。视觉渲染不变。修法是一行 HTML。开发成本大约 30 秒。收益是这个功能终于能被看不到它的用户听到了。

同一个模式适用于所有 emoji-as-label 场景:背负含义的 emoji("刚上线"用 ✨)、emoji 当状态(在线用 🟢)、emoji 当章节标题(小贴士用 💡)。每一个都需要 role="img" + aria-label 组合,让屏幕阅读器朗读出想表达的含义。每一个修法都是一行 HTML。

关于 emoji 的常见无障碍错误

• •把 emoji 当标题用、却没有加 role="img" 属性 ， 屏幕阅读器朗读的是 CLDR 短名,而不是标题文字
• •在同一个视觉标签里把 emoji 和文字合在一起、却没有 aria-label ， 屏幕阅读器会把两者都读出来,经常是冗余的
• •用纯 emoji 按钮、却没加隐藏文字替代 ， 按钮朗读出来就是一个 emoji 码点,用户完全不知道这个按钮是干什么的
• •靠 emoji 颜色传达含义(红圈 = 错误、绿圈 = 成功)， 单靠颜色传达含义,在每一次重大无障碍审计里都会失败
• •加肤色修饰符、却没提供语境 ， 修饰符不会被朗读出来,当 emoji 被用来代表某个具体的人或身份时,会引起困惑
• •把多个 emoji 顺序排开、却没有包一个总标签 ， 屏幕阅读器朗读出来是一串 emoji 名称、彼此之间毫无关联

上面这 6 个错误,我们为下面数据部分所审计过的生产环境网站里全都见过。修起来都不难,也不需要重新设计页面。它们是行级 fix,任何开发者都能在一个 PR 里上线。

实战示例:纯 emoji 导航

一个更严重的场景是纯 emoji 导航 ， Slack、Discord、Twitter DM 在 UI 的某些部分都使用纯 emoji 图标。一个常见的模式:消息反应按钮就只有一个笑脸 emoji。屏幕阅读器用户在导航到那个按钮时听到 "face"(某个 emoji 的 CLDR 短名),完全不知道这个按钮是干什么的。

修法是加一段隐藏文字。Slack 和 Discord 内部都已经这么做了 ， 它们 UI 里的每个纯 emoji 图标都有一段视觉上隐藏的标签,屏幕阅读器会朗读出来。标签使用 UI 的语言,描述按钮做什么:"add reaction"(添加反应)、"send message"(发送消息)、"open menu"(打开菜单)。可见的 emoji 是装饰性的,隐藏的标签才是真正的语义内容。

当你构建一个用 emoji 当图标的 UI 时,你得自己提供这个标签。模式:<button aria-label="Add reaction"><span aria-hidden="true">😊</span></button>。按钮上的 aria-label 就是屏幕阅读器朗读的内容。里面的 emoji 是装饰性的,会被屏幕阅读器隐藏。视觉渲染不变。

同一套模式适用于纯 emoji 的标签页、菜单项、状态指示器。每一种 emoji-as-icon 场景都需要在父控件上加 aria-label,同时在 emoji 本身加 aria-hidden="true"。两个属性,五分钟工作量。这个修法是你能上线的投入产出比最高的无障碍改进之一。

Forgemoji 用户群的真实数据

我们审计了 Forgemoji 用户群里最大的 50 个 Discord 服务器的 emoji 无障碍状况,结果让人警醒。67% 的服务器至少存在一处 emoji 被当作文字标签使用、却没有加 aria-label 或 role 属性的情况,这意味着屏幕阅读器用户听到的是 CLDR 短名,而不是想表达的含义。22% 的服务器名字是纯 emoji(也就是 Discord UI 中显示的服务器名完全由 emoji 组成,没有文字替代)。8% 的服务器以会让至少一款主流屏幕阅读器读起来具有排斥性的方式使用肤色修饰符。

每一种情况的修法都一样:为每一个承载含义的 emoji 提供文字替代,每一个不承担含义的 emoji 用 aria-hidden。我们已经上线了一个默认带元数据标签的 emoji 生成器,任何支持元数据感知渲染的平台都会朗读出正确的名字 ， 但平台支持参差不齐,上面这 7 个模式在 2026 年反而是更稳妥的选择。

推荐继续阅读

• •我们如何打造一个支持透明 PNG、GIF、WebP 导出的 AI Emoji 生成器 ， 自定义 emoji 的技术设计
• •2026 年如何制作自定义 Discord emoji:完整指南 ， 实际场景中的无障碍设计
• •2026 年 emoji 俚语词典 ， 跨平台理解语境与含义

参考资料