为何无障碍访问与同意现已相互交叠

GDPR 要求同意必须能够被每位用户获取，而不仅仅是那些能看到并点击横幅的用户。欧洲数据保护委员会已明确指出，如果数据主体因网站未进行无障碍适配的残障而无法与同意界面进行有意义的交互，则同意不属于有效获取。这意味着相关 Cookie 根本就不应该加载。

在无障碍访问层面，已在欧盟成员国国内法中转化的欧洲无障碍法案（EAA）将 WCAG 2.1 AA 设定为提供消费者服务的私营部门网站和应用的最低标准。处罚制度因国而异，但通常每次违规罚款从 50,000 欧元到 500,000 欧元不等，持续不合规还将面临市场退出令。

Cookie 横幅的核心 WCAG 要求

键盘可操作性

横幅上的每个控件——接受、拒绝、管理偏好、关闭——必须仅凭键盘即可访问和操作。用户应能按逻辑顺序通过 Tab 键在按钮间切换，并用 Enter 或 Space 激活它们。焦点必须可见，且与背景的对比度至少为 3:1。

模态横幅中的焦点锁定

如果横幅阻止与页面其余部分的交互，则键盘焦点必须被锁定在横幅内，直到用户做出选择。用户不应能通过 Tab 键跳出横幅去滚动底层页面。当焦点被锁定且横幅关闭后，焦点应返回到触发横幅的元素或合理的默认位置。

屏幕阅读器朗读

横幅必须以带有可访问名称和角色的对话框形式被朗读。使用 role="dialog" 或 role="alertdialog"，并配合 aria-labelledby 指向横幅标题，aria-describedby 指向说明文本。

颜色对比度

正文文本与背景的对比度必须达到 4.5:1；大文本（18pt 以上或 14pt 粗体）需达到 3:1。按钮文字、图标和焦点指示器都有各自的最低对比度要求。在白色背景上使用浅灰色"拒绝"按钮是我们在审计中经常发现的 WCAG 违规情况。

不依赖单一颜色提示

不要仅靠颜色来区分接受和拒绝。使用不同的标签、图标或形状，以便色盲用户能够区分这两个按钮。

暗黑模式与无障碍访问

WCAG 2.2 引入了直接针对暗黑模式的新标准——这与同意尤为相关：

• 3.3.8 无障碍身份验证——禁止将认知谜题作为同意摩擦。
• 3.3.7 冗余输入——用户不应仅为撤回同意而重新输入信息。
• 2.4.11 焦点不被遮挡——横幅本身不应遮挡其背后元素的焦点指示器。
• 2.5.7 拖拽动作——如果您的横幅使用拖拽接受交互，则必须提供单指针替代方案。

RTL 与国际化

无障碍访问延伸至从右到左的语言（阿拉伯语、希伯来语、波斯语、乌尔都语）以及屏幕阅读器发音：

• 当文档语言为 RTL 时，在横幅上设置 dir="rtl"，使按钮顺序和焦点流向与阅读方向一致。
• 在翻译后的横幅文本上使用正确的 lang 属性，使屏幕阅读器以正确的语音发音朗读文字。
• 镜像图标——箭头、尖括号和进度指示器应针对 RTL 语言环境进行翻转。

测试您的横幅以符合 WCAG 合规

不要只依赖单一工具。将自动扫描与真实辅助技术测试相结合：

• axe DevTools 或 Lighthouse——自动捕获约 30-40% 的 WCAG 违规。
• Windows 上的 NVDA 或 JAWS，Mac/iOS 上的 VoiceOver，Android 上的 TalkBack——使用真实的屏幕阅读器进行测试。横幅能否仅通过屏幕阅读器被朗读、导航和关闭？
• 纯键盘导航——拔掉鼠标。如果您无法通过键盘接受、拒绝和管理偏好，键盘用户同样无法做到。
• 色盲模拟——Chrome DevTools 内置了视觉障碍模拟器。检查在红色盲、绿色盲和蓝黄色盲下，接受和拒绝按钮是否可区分。
• 放大至 400%——WCAG 要求内容在 400% 缩放时无需横向滚动仍可正常使用。固定定位的横幅通常无法通过此测试。

我们发现的常见无障碍问题

• 将拒绝隐藏在齿轮图标后——暗黑模式加无障碍失败（图标按钮无可访问名称）。
• 焦点从未到达横幅——横幅吸引了视觉注意但在 Tab 顺序中被跳过。
• 模态横幅没有焦点锁定——用户可以在横幅声称阻止交互时 Tab 进入背景页面。
• 偏好更改时没有 aria-live——屏幕阅读器用户听不到其选择已保存的确认。
• 翻译后的横幅没有 lang 属性——屏幕阅读器用英语语音发音朗读西班牙语文本。

FlexyConsent 如何提供无障碍访问