HTML 邮件终究还是由用户代理渲染的 HTML——网页邮箱客户端本质上就是浏览器,而原生邮件应用的渲染引擎与之也没有根本区别。 WCAG 的成功标准并没有专门为邮件划出例外,它们同样直接适用于纯 CSS 构建的投票、测验或手风琴,就像适用于对应的网页组件一样。本文是一份实用检查清单,涵盖对基于 checkbox hack 技术的互动邮件最重要的四项标准。
为什么 WCAG 在这里同样适用
WCAG 2.2 的措辞是由"用户代理"渲染的"内容",而不是特指"网页"——它并不是一项正式的、专门针对邮件的标准,因为邮件作为一种媒介根本没有在规范中被提及,但无论如何,底层的内容都是 HTML。这正是为什么无障碍社区会把 WCAG 的成功标准当作衡量邮件内容的实用基准,本清单也是如此,而不是把邮件当作规范触及不到的独立类别。
1.1.1 非文本内容——每张图片都需要真正的 alt
产品照片、主视觉图片、装饰性分隔线,以及纯图标按钮,都需要一个屏幕阅读器可以朗读的 alt 属性——对于真正不承载任何信息的纯装饰性图片,则需要显式设置一个空的 alt="",让屏幕阅读器跳过它们,而不是朗读一个毫无意义的文件名。这一点在互动模块中比在静态模块中更为重要:一个完全靠图片驱动的转盘抽奖或刮刮卡揭晓模块,如果没有文字替代方案来描述结果,会让使用屏幕阅读器的用户完全无从知道自己抽中了什么。
1.4.3 / 1.4.11——文字与互动控件的对比度
WCAG 为正文文字设定了 4.5:1 的最低对比度(大号文字为 3:1,依据 1.4.3),并为 UI 组件与图形的视觉边界设定了 3:1 的最低对比度(1.4.11)。这两项标准都直接适用于互动元素,而不仅仅是段落文案——一个投票选项的边框、一个测验答案按钮相对其容器的背景色、一个倒计时数字相对其背景的颜色。一个低对比度的互动控件不只是审美上的缺陷;它甚至可能让低视力的收件人完全看不见这个控件。
2.1.1 键盘——checkbox hack 技术真正的优势
一个真正的 <input type="radio">/<input type="checkbox"> 搭配 <label for="...">,在任何能渲染表单控件的客户端中,原生就是可获得焦点、并可通过 Tab 加空格键或回车键操作的——不需要额外标记,也不需要额外工作,因为浏览器向来就是这样对待真正的表单控件的。这项技术本身的运作方式详见 CSS :checked 状态机。相较于一个由 JavaScript 驱动的网页轮播图通常的做法——一个没有键盘处理逻辑的 <div onclick>——这是一项真正的优势,而且只要使用真正的 <label>/<input> 组合、而不是裸露的可点击 <div>,互动邮件天生就能获得这项优势,不需要额外投入。
2.5.8 目标尺寸(最小值)——WCAG 2.2 新增标准
WCAG 2.2 新引入的成功标准 2.5.8,为互动目标设定了 24×24 CSS 像素的下限,并对行内文字、必要的布局限制,或在别处提供的等效更大控件设有例外。这一标准在移动端最为相关——大多数邮件打开都发生在移动端——尤其针对工作室中容易被缩得过小的那些最小互动元素:轮播图指示点、星级评分图标,以及紧密排列在一起的测验答案选项。
4.1.2 名称、角色、值——正确标注 :checked 控件
屏幕阅读器会从真正的语义化标记中读出一个控件的名称、角色和当前状态——而一个包裹着真实 <input> 的 <label> 恰好免费提供了这些信息,而一个用来充当按钮的、裸露的带样式 <div> 恰恰缺失了这些信息。这在实践中意味着,每一个投票选项、测验答案和手风琴标题,都需要屏幕阅读器可以朗读的真实标签文字,而不能只是一张背景图片或一个没有配套文字的图标。
实用检查清单
- 每张图片都带有真实的
alt,若为装饰性图片,则显式设置空的alt=""。 - 互动控件的文字和边框对比度分别满足 4.5:1(文字)/ 3:1(UI 组件)。
- 每一处
:checked互动都使用真实的<input>+<label for="...">组合——绝不使用裸露的可点击<div>。 - 互动目标至少为 24×24 CSS 像素,面向移动端的模块尤其要注意这一点。
- 投票、测验、手风琴的标签都带有真实、可读的文字,而不仅仅是图片或图标。