你的功能通过了单元测试，QA 也说没问题——但真的没问题吗？要真正确认无误，以下四类测试应该被视为从一开始就至关重要的。包括这些测试，可以提高功能的可访问性，并帮助用户顺利完成任务。
颜色对比度
是的，又是这个老生常谈的议题——这是你在任何功能发布中都能改善的最简单部分。根据 2022 年的 WebAIM Million 报告，测试的首页中有 83.9% 存在文本颜色对比问题，成为检测到的首要错误。
WCAG AA 的最低对比度标准如下：
- 正常文本的对比度为 4.5:1
- 大文本（定义为 18.66px 加粗或更大，或 24px 及以上）的对比度为 3:1
- 图形和用户界面组件（如表单输入框边框）的对比度为 3:1
WCAG 3 正在考虑一种名为 APCA 的新颜色对比模型，但要成为标准还需要几年时间。在此之前，最好坚持现行模型，特别是由于行业或国家法规的要求，基于 WCAG 2.x 可能还存在法律责任。
设计工具、开发工具和众多在线工具中都提供了颜色对比度检查功能。我个人还喜欢使用 Mac 桌面工具 Contraste App，它可以从屏幕的任何窗口中挑选颜色进行比较。
通过自动化工具也可以相对容易地检测颜色对比，例如以下浏览器插件：
- WebAIM 的 WAVE（用于生成上述报告）
- axe
- Accessibility Insights FastPass（使用了带有额外功能的 axe-core）
我最喜欢的一些在线颜色对比检查和选择工具包括：
- WebAIM Contrast Checker
- tanaguru contrast finder：帮助找到最接近的对比色对
- contrast ratio：一个简单的视觉检查器，用于测试对比色对，并生成唯一的 URL
- Colour Contrast Checker：另一个 Web 应用，带有调色控件，可调整颜色并生成唯一 URL 分享，也可作为浏览器扩展使用
交互元素的颜色对比
我们通常专注于文本对比，因此用户界面组件的对比常常被忽略。特别棘手的是交互元素的不同状态下的对比。例如，按钮可能需要考虑五种对比情况！
信息图：一个"默认"按钮为中等紫色，带有白色字母，旁边是"焦点"状态的按钮，呈现较深的紫色。图标和标签显示，默认紫色与浅黄色页面背景的对比度为 4.17，默认紫色与白色文本的对比度为 4.5。对于焦点按钮，默认紫色背景与焦点紫色背景的对比度为 3.02，焦点紫色与按钮白色文本的对比度为 13.62，焦点紫色与页面浅黄色背景的对比度为 12.57。
额外颜色修复：Windows 高对比度模式
这是额外的提示，但解决此模式对颜色对比的影响确实是基本要求！
一些用户可能会修改他们的 Windows 机器，使用“高对比度”主题，这对应于 CSS 的“强制颜色”规范。在这种模式下，几乎所有颜色都会被替换为简化的调色板。这可能导致图标失去意义，使重要的图形（如你的 logo）不可见，或破坏用户界面元素之间的边界。
了解更多关于处理高对比度/强制颜色模式的 CSS 技术。
键盘交互
如果某个交互依赖于鼠标触发操作，它也需要能够通过键盘访问。这意味着它可能需要响应 Space 和/或 Enter 键作为触发器（提示：使用 <button> 可以自动获得此功能）。
以下是评估你功能时需要注意的一些键盘交互：
- 如果它打开了某个内容，它也需要能够通过 Escape 键关闭。
- 如果它可滚动，需要响应上下箭头键。
- 如果它是一组相关选项（如自动完成或选项卡），可能需要响应上下箭头键或左右箭头键（关键词：roving tabindex）。
- 如果它打开了对话框/模态框，需要阻止对体验外元素的 Tab 键访问（关键词：“焦点捕捉”和“inert”）。
- 如果它是交互式的，必须能够通过键盘获取焦点，并且该焦点必须有可见样式（这就是测试 #3）。
- 如果可视鼠标用户可以进行独立选择（如自动完成），键盘用户也必须能够做到。这通常意味着允许结合 Tab、箭头键和 Enter 键进行探索并选择。
- 如果 :hover 触发了内容，那么 :focus 也应该触发（例如菜单）。你还需要一种方法来关闭该内容，无论是点击页面其他地方还是按 Escape 键，并确保这种方法对触摸屏用户也可访问。
当你试图为交互体验创建一个“纯 CSS”解决方案时，很可能无法满足这些条件。要确保界面的无障碍性，JavaScript 是必需的，它能够实现焦点管理、响应键盘事件并切换 ARIA 属性。我在 Smashing 的文章中回顾了无障碍自定义控件的 JavaScript 要求。
可见的焦点
可聚焦的元素需要可见的焦点，以便视力正常的键盘用户能够跟踪页面上焦点所在的位置。“可见”意味着在失去焦点和获得焦点的状态之间存在变化——通常是轮廓，有时是颜色变化。
原生可聚焦的元素包括：
- 表单控件：input、select、textarea
- button
- a（链接）
- summary
定义焦点状态的规则属于 WCAG 2.4.7 - 焦点可见，并且在 WCAG 2.2 中有更详细的规定，即 2.4.11 - 焦点外观（最小值），目前它还是一个草案，但已接近最终确定。
通常，移除焦点的原因是觉得浏览器默认的焦点样式不够美观或不符合应用的设计选择。多年来，这导致开发者完全移除了焦点轮廓，却没有为其提供备选样式。
在 2021 年，主流浏览器实际上将其默认的焦点行为切换为现代 CSS 伪类选择器 :focus-visible，该选择器旨在仅根据启发式算法显示默认轮廓。实际上，这通常意味着在检测到键盘导航时，它会显示可聚焦控件的轮廓，但不会在鼠标点击时显示。这种功能消除了“焦点样式丑陋”这一观点的影响，因为它减少了轮廓样式出现的情况。
测试时要确保你允许了浏览器的默认样式，或者自定义的焦点样式符合 WCAG 的标准。Sara Soueidan 创建了一个全面的指南，帮助设计符合 WCAG 标准的无障碍焦点指示器。
请查看我关于使用自定义属性标准化焦点样式的技术，设计一种既一致又灵活的方法，以管理整个网站或应用程序的焦点。
缩放级别
你已经使用浏览器开发工具和真实的移动设备测试了不同视口大小，并对网站的响应式行为感到满意。但你可能遗漏了一个测试点：桌面缩放。
WCAG 1.4.10 - 重排 规定，功能应支持桌面缩放至 400%。在如此高的缩放级别下，你的布局可能会切换到你认为的“移动”布局，但重要的是，这些用户的使用环境是不同的。此外，他们的屏幕宽高比更接近于横向（宽度大于高度），而你的“移动”样式可能假设默认的纵向（高度大于宽度）方向。
视口宽度并不能完全代表用户或设备的能力！
以下是一些可能出现的问题，当你的布局无法适应高倍缩放时：
- 粘性导航覆盖了一半或更多的视口
- 假设纵向布局的滚动区域变得不可滚动或内容被截断
- 使用流体排版技术时产生意外效果
- 内容被截断或重叠
- 相对于内容大小，边距和内边距显得过大
从一开始的功能开发阶段就纳入这些测试，而不仅仅是在最后阶段进行测试。与设计师、项目经理，甚至业务所有者分享这些知识。
网友评论