电子邮件无障碍指南：构建包容性 HTML 邮件

对于大多数组织来说，电子邮件是它们与客户最频繁的接触点。订单确认、密码重置、月度对账单、新闻通讯——这些消息往往在有人访问你的网站之前就已经到达，而且到达得频繁得多。然而电子邮件无障碍却是数字包容性中最被忽视的角落之一。那些在无障碍网站上大量投入的团队，却常常发送基于杂乱标记、纯图片内容以及屏幕阅读器读作”点击这里”的按钮所构建的营销活动。

原因部分是历史性的，部分是技术性的：HTML 邮件是一门独立的学科，有自己的约束、自己的渲染引擎和自己的失败模式。那些在现代 Web 上习以为常的技术——语义化地标、flexbox 布局、CSS 自定义属性——在邮件客户端矩阵中要么不可靠，要么彻底失效。让一封邮件无障碍与让一个网页无障碍不是同一项工作，而将二者视为相同正是如此多邮件失败的原因。

本指南将逐一讲解电子邮件无障碍真正需要什么：如何组织标记以便辅助技术能够解析它，如何处理至今仍支撑邮件布局的布局表格，如何编写脱离上下文也讲得通的替代文本和链接，如何在深色模式和缩放下存活，以及如何跨 Outlook、Gmail、Apple Mail 和屏幕阅读器测试结果。如果你更愿意让专家为你的模板完成这项工作，我们的邮件修复服务涵盖了整个技术栈。

为什么 HTML 邮件是一门独立的学科

网页在浏览器中渲染。主流浏览器只有少数几款，它们按可预测的时间表更新，并向 Web 标准靠拢。邮件则恰恰相反。你的消息可能在数十种客户端中被打开——Windows 上的 Outlook、网页版 Outlook、新版 Outlook、浏览器中的 Gmail、Gmail 应用、macOS 和 iOS 上的 Apple Mail、Yahoo、Samsung Email 等等——每一种都有不同的渲染引擎，以及不同的、往往在缩减的受支持 HTML 和 CSS 子集。

最臭名昭著的例子是 Windows 上的桌面版 Outlook，它历来使用 Microsoft Word 的引擎而非真正的浏览器引擎来渲染邮件。仅此一点就迫使邮件开发者回到基于表格的布局、内联样式以及 Web 多年前就已放弃的防御性模式。许多客户端还会剥离 <style> 块、拒绝现代 CSS，并重写它们认为不安全的属性。

对于无障碍而言，这极其重要。你在网站上所依赖的语义化 HTML——<nav>、<main>、ARIA 地标——在邮件中常常被剥离或忽略。你无法依赖单一的渲染目标。因此电子邮件无障碍的关键在于构建能够优雅降级的消息：即使布局崩溃、图片加载失败或样式被丢弃，它们仍然保持可读、可导航且有意义。这种防御性思维是本指南其余一切的基础，也是邮件应当归入专门的无障碍服务计划，而非被并入一般 Web 工作的原因。

语义结构与合乎逻辑的阅读顺序

即便存在所有这些约束，你能为屏幕阅读器用户做的最有价值的一件事，就是赋予邮件清晰、线性的结构。屏幕阅读器按 DOM 顺序读取内容，因此你标记的顺序就是消息被听到的顺序。如果你的设计把促销横幅放在实际消息之前，那么横幅会先被朗读——无论布局看起来如何。

使用真正的标题元素来建立层级。一封邮件应当有一个合乎逻辑的顶级标题（通常是主要主题或优惠）作为 <h1>，后续各部分标记为 <h2> 和 <h3>。屏幕阅读器用户通过标题导航来浏览消息，因此一份结构良好的大纲能把一堵文字墙变成可快速浏览的内容。不要用又大又粗的 <span> 文本伪造标题；视觉上它可能看起来像标题，但辅助技术听到的是普通正文。同样，对列表使用真正的列表标记（<ul>、<ol>、<li>），并通过 <html> 元素上的 lang 属性设置文档语言，以便屏幕阅读器使用正确的发音和语音。

阅读顺序本身也必须讲得通。从上到下阅读你的标记，忽略所有样式，并自问它是否仍然讲述了一个连贯的故事。如果是，你就有了坚实的基础。如果含义取决于视觉排列，那你还有工作要做——而这项工作通常从布局表格开始。

布局表格与 role=“presentation”

邮件布局是用表格构建的。这不是风格选择；而是生存所需，因为基于表格的布局是唯一能在客户端矩阵中一致渲染的方法。问题在于表格承载语义含义。默认情况下，屏幕阅读器会将 <table> 宣告为数据表格，读出行数和列数，并尝试将单元格与表头关联。对于一个纯粹为了将徽标放在标题旁边而存在的表格，这种宣告就是噪音——而在一封嵌套的、多表格的邮件中，它会变成一种令人疲惫、迷失方向的体验。

解决办法是告诉辅助技术这些表格是布局脚手架，而非数据。给每一个用于布局的表格添加 role="presentation"：<table role="presentation">。这会移除表格的语义，使屏幕阅读器跳过行/列宣告，仅按顺序读出其中的内容。这是电子邮件无障碍中最重要也最常被遗漏的技术之一，而且必须应用于每一个布局表格，包括嵌套的表格，而不仅仅是最外层的包装表格。

几项相关实践可以强化这一点。不要给演示表格添加 summary、<th> 表头单元格、scope 或 <caption>——这些是为真正的数据表格保留的、承载含义的标记。如果你的邮件包含真正的表格数据，比如逐项列出的收据，则反其道而行之：将其保留为数据表格，配以正确的 <th> 表头和 scope 属性，以便传达这些关系。原则是外观与语义之间的一致性。要在整个模板库中做对这一点既繁琐又容易回退，这正是它成为我们邮件修复工作核心部分的原因。

图片与替代文本

图片在邮件中承载了很大分量，而许多收件人在默认禁用图片的情况下查看它们——一些客户端会阻止远程图片，直到用户选择启用。这使得替代文本加倍重要：它既是无障碍要求，也是当图片无法加载时让你的消息保持可理解的后备方案。

每个 <img> 元素都需要一个 alt 属性。里面写什么取决于图片的用途。对于信息性图片——产品照片、信息图、图表——替代文本应当传达图片所提供的相同信息。“蓝色跑鞋，侧视图”比”image1.png”更有用，而图表的替代文本应当概括其要点，而不仅仅将其标注为图表。对于以图片形式呈现的文本（在促销标题中仍会出现），替代文本必须精确再现这些文字，否则该内容对屏幕阅读器以及任何关闭图片的人都是不可见的。

对于装饰性图片——间隔元素、背景修饰、对含义毫无贡献的分隔线——使用空的 alt 属性，写作 alt=""。这会明确告诉屏幕阅读器跳过该图片，而不是宣告一个文件名。完全省略该属性并不等同；缺失的 alt 往往会导致屏幕阅读器读出图片的 URL，这是两全其下的结果。对于将图片用作按钮或链接这一常见模式要格外小心：该图片的替代文本必须描述操作，比如”完成购买”，而不是这张图片本身。

还有一个邮件特有的要点：切勿将关键信息仅放在图片中。优惠码、确认编号、退订链接、核心行动号召——如果其中任何一项仅以像素形式存在，它就会对关闭图片和使用屏幕阅读器的用户消失。请将关键内容保留为可实时选择的文本。

对比度与深色模式

文本必须可读，这意味着它必须满足对比度要求。WCAG 2.2 要求普通文本相对于其背景的对比度至少为 4.5:1，大号文本为 3:1。白色背景上的浅灰色文本——极简邮件设计的常年宠儿——经常不达标，浅色按钮和低对比度的链接颜色也是如此。这些阈值适用于邮件，正如适用于 Web 一样，而且同样以 WCAG 2.2 的成功标准作为基准；我们更全面的 WCAG 合规概述解释了这些标准如何相互配合。

邮件增加了一个 Web 大多没有的复杂因素：深色模式。许多客户端——其中包括 Apple Mail、Outlook 和 Gmail——会在用户启用深色模式时自动转换邮件。有些只是替换背景；有些则会激进地反转或重新着色你的调色板，有时是部分地。结果是，一个在浅色品牌色上有深色文本的按钮，可能最终变成深色反转背景上的深色文本，使对比度降至零。彩色框中的黑色文本可能变得不可见。带透明背景的徽标可能在深色画布上消失。

对于深色模式没有通用的控制方法，现有技术也因客户端而异，但防御性原则是稳定的。设计时要兼顾两种模式。避免使用纯黑或纯白作为基础颜色，因为它们没有给客户端留出调整余地。给徽标和关键图形添加对比鲜明的轮廓或实心背景底板，使其在反转中存活。在每个主流客户端的深色模式下测试实际渲染的结果，而不是信任你的浅色模式设计会自动转换。目标是无论客户端如何翻转，文本和交互元素都保持在对比度阈值之上。

描述性链接与无障碍按钮

屏幕阅读器用户经常调出消息中所有链接的列表来导航或决定去哪里。在该列表中，链接文本以剥离其周围上下文的形式出现。一封满是”点击这里""阅读更多”和”了解更多”的消息会产生一份毫无用处、由相同且无意义的条目组成的清单。每个链接的文本都应当本身就讲得通：“阅读我们的春季可持续发展报告”或”跟踪你的订单”无需任何周围句子就能准确告诉用户链接通向何处。

按钮同理，在邮件中按钮通常是被设计成看起来像按钮的链接——常常用”防弹按钮”技术，通过嵌套表格和背景颜色构建，以便在各客户端中渲染。无论采用何种构建方式，按钮的无障碍名称都必须描述其操作。一个空的或含糊的按钮，或一个文本只存在于背景图片中的按钮，对辅助技术来说是死胡同。如果按钮基于图片，操作应当放在图片的替代文本中。

让链接和按钮的目标足够大以便舒适点按——WCAG 2.2 引入了最小目标尺寸，而在移动设备上，过小的点按目标会让所有人沮丧，而不仅仅是有运动障碍的用户。确保链接通过不止颜色的方式可区分，因为仅靠颜色的链接对低视力或色盲用户会失效；下划线是最可靠的提示。并且给每个链接一个真实、有效的目标地址，而不是占位符。含糊的链接文本是我们见到的最常见的失误之一，它在 Web 上也会出现，而不仅在邮件中——我们关于应避免的常见无障碍问题的综述在更广阔的语境中涵盖了同样的模式。

预览文本与预览体验

预览文本（preheader，有时称为预览文字）是在消息被打开之前，出现在收件箱中主题行旁边或下方的那段文字。许多邮件浪费了它，听任它默认为碰巧排在最前的任何文本：一行”邮件显示不正常？“、一个”退订”链接，或一串空的替代文本。对于在收件箱中导航的屏幕阅读器用户，以及对于每一个决定是否打开的人，那段被浪费的预览文本都是一个错失的沟通机会。

撰写一段刻意而有意义的预览文本来概括邮件的目的，并将其放在正文中作为第一段文本内容，使它成为收件箱所抓取的内容。标准技术是在邮件顶部附近放置一段隐藏的文本块，将其设置为视觉上隐藏但仍可供客户端和辅助技术使用。要小心你隐藏它的方式：隐藏得不好的预览文本可能显示为一行不需要的可见文字，或者被屏幕阅读器完全跳过。适当地填充它，使后续的收件箱内容不会将相邻文本泄漏到预览中。

将预览文本视为消息信息架构的一部分。结合清晰的主题行和有力的开篇标题，它能让每一位收件人——无论是否视力正常——快速而准确地感知这封邮件是什么以及为何重要。

响应式布局与缩放

邮件在手机上被阅读的频率不亚于在桌面上，而且被那些放大以增大文本的人阅读。两者都要求布局能够自适应。一个固定的、宽幅的布局，在小屏幕上迫使横向滚动，或在用户增大文本尺寸时崩坏，就是一道障碍——而 WCAG 2.2 对回流和文本间距都有适用于此处的标准。

将邮件构建为响应式：在窄屏幕上采用单列布局几乎总是最稳健、最无障碍的选择，因为它保留了阅读顺序，并避免了会不可预测地崩坏的并排内容。在你使用媒体查询切换布局之处，记住有些客户端会忽略它们，因此默认渲染仍必须可用。将字号设置得足够大以便无需缩放即可阅读——正文低于约 14 至 16 像素对许多人在移动设备上来说很吃力——并避免将行高或字母间距固定得过于紧凑，以致放大后的文本重叠或被裁切。

测试当用户放大或增大设备系统字号时会发生什么。内容应当回流并保持可读，而不是溢出其容器或消失在其他元素之后。回报是一封不仅适用于低视力用户、也适用于每一个在不完美条件下用小屏幕阅读的人的邮件。

跨客户端和屏幕阅读器测试

你无法仅通过检查代码来验证电子邮件无障碍，因为整个挑战恰恰在于客户端会以不同方式渲染相同的代码。测试必须跨一个有代表性的客户端和辅助技术矩阵进行，在真实收件人所使用的条件下进行。

至少覆盖主要客户端：Outlook（Windows 上的桌面版，以及网页版和新版本）、Gmail（网页版和移动应用）和 Apple Mail（macOS 和 iOS）。对于每一个，都检查在浅色和深色模式下、图片开启和关闭、以及放大缩放时的渲染。然后在其上叠加屏幕阅读器——macOS 和 iOS 上的 VoiceOver 配 Apple Mail，Windows 上的 NVDA 或 JAWS 配 Outlook 和 Gmail，以及 Android 上的 TalkBack 配 Gmail 应用。像屏幕阅读器用户那样聆听这封邮件：标题是否被宣告，阅读顺序是否合乎逻辑，布局表格是否保持沉默，链接在链接列表中是否讲得通，图片是否宣告有用的替代文本或在装饰性时保持安静？

自动检查有其用武之地——它们可以在许多模板中快速标记出缺失的 alt 属性、低对比度和缺失的语言属性——但它们无法判断替代文本是否有意义、阅读顺序是否讲述了正确的故事，或按钮的名称是否描述了其操作。这种判断需要手动测试，理想情况下包括由每天使用辅助技术的人进行测试。我们的人工无障碍审计指南解释了为何人工测试不可替代，而我们的由残障人士进行的审计正是将这种亲身经历的视角带入邮件。

一句忠告：不要被那些承诺即时合规的无障碍”覆盖层”小部件所诱惑。它们对网站不起作用，而且与邮件无关，因为那里没有可供注入脚本的页面。真正的电子邮件无障碍来自修正标记，而非外挂式附加组件。

在 ESP 层面修复模板

修复一封邮件有用。修复生成每一封邮件的源头则具有变革性。大多数组织通过电子邮件服务提供商发送——Mailchimp、Klaviyo、Salesforce Marketing Cloud、Braze 等等——在那里营销活动由母版模板、可复用模块和拖放式内容块组装而成。如果这些底层模板携带了无障碍修复，那么未来每一次发送都会自动继承它们，营销团队也无需为每个活动记住一份检查清单。

这是投入产出最高的地方。修复母版模板，使布局表格携带 role="presentation"、设置好语言属性、就位预览文本结构，并使标题脚手架正确无误。修复每个可复用模块——主视觉块、文章卡片、按钮、页脚——使团队拖入的任何内容在构建上即是无障碍的。建立替代文本的模式，以便提示编辑撰写它，并将对比度安全、考虑深色模式的颜色烘焙进模板所使用的品牌调色板中。

问题在于，拖放式构建器也可能使无障碍回退：构建器可能剥离 role="presentation"、在导出时损坏标记，或让编辑粘贴进一个不无障碍的块。因此模板修复必须与治理相配合——准则、审查步骤，以及随着 ESP 及其导出行为变化而进行的定期重新测试。这正是将无障碍融入工作流的回报所在；我们的无障碍流程改进服务帮助团队让无障碍邮件成为默认，而非事后补救，而无障碍咨询将其与你更广泛的合规计划对齐。对于受《欧洲无障碍法案》约束的组织，无障碍的客户沟通是整体图景的一部分，我们的 EAA 合规概述对此作了阐述。

QualiBooth 将无障碍扫描软件用于机器能可靠捕捉的问题，与专家人工修复用于机器无法做出的判断相结合——网站、文档和邮件无一例外。如果你的邮件是你服务客户方式的一部分，它们理应获得与你数字资产其余部分同等的严谨对待。

结论

电子邮件无障碍不是 Web 无障碍的缩小版——它是一门相关但独立的学科，由碎片化的客户端格局、基于表格的布局，以及忽略大部分现代 Web 的渲染引擎所塑造。好消息是这些技术已经成熟：语义结构和合理的标题大纲、每一个布局表格上的 role="presentation"、有意义的替代文本以及装饰用空 alt、在深色模式中存活的对比度、自我描述的链接和按钮、刻意的预览文本、经得起缩放的响应式布局，以及跨客户端和屏幕阅读器的严谨测试。在模板层面应用它们，无障碍便不再是每个活动的琐事，而成为你系统的一项属性。

回报是真实的。无障碍邮件触及更多人，在关闭图片时也读得清晰，而且往往表现更好，因为清晰和稳健对所有人都有帮助。如果你需要帮助，我们的邮件修复服务可以审计你的模板、在 ESP 层面修复它们，并在整个客户端矩阵中验证结果——你还可以预约演示或对你的网站运行一次免费扫描，看看你数字资产的其余部分处于什么状况。

常见问题

我真的需要在每个布局表格上都加 role="presentation" 吗？ 是的。没有它，屏幕阅读器会将每个布局表格宣告为数据表格，读出行数和列数并打断流程。由于邮件布局会嵌套表格，该属性必须加在每个布局表格上，而不仅仅是外层包装表格。真正的数据表格，比如收据，则反而保留其数据语义。

装饰性图片的替代文本里该写什么？ 使用空的 alt 属性，写作 alt=""，以便屏幕阅读器跳过该图片。不要完全省略该属性，因为缺失的 alt 往往会导致图片的文件名或 URL 被朗读出来。

我该如何阻止深色模式破坏我的邮件？ 你无法完全控制每个客户端如何处理深色模式，但你可以进行防御性设计：避免纯黑和纯白，给徽标添加对比鲜明的背景或轮廓，使对比度保持在 WCAG 2.2 阈值之上，并在每个主流客户端的深色模式下测试渲染结果，而不是假定你的浅色模式设计会自动沿用。

自动化工具能让我的邮件无障碍吗？ 自动化工具能捕捉一些问题——缺失的 alt 属性、低对比度、缺失的语言设置——但它们无法判断替代文本是否有意义、阅读顺序是否讲得通，或链接和按钮是否描述了其用途。这需要使用屏幕阅读器进行手动测试。无障碍覆盖层小部件不是解决方案，也不适用于邮件。

修复单封邮件还是修复模板更好？ 模板。在你的 ESP 中修复母版模板和可复用模块，意味着未来每一次发送都会继承这些修复，这远比逐个修复活动更具成本效益。将其与治理相配合，使拖放式构建器不会重新引入问题。