当无障碍访问并不容易：需要特别关注的网站功能

想进一步探索这个话题吗？加入我们于美国东部时间8月15日下午12点举办的现场 无障碍访问网络研讨会，与哈佛大学数字无障碍服务经理珍妮尔·西姆斯一同探讨。

当我们谈论网页无障碍访问时，很容易只关注指南和清单。但实际上，网站上并非每个功能都易于实现无障碍访问。像自定义搜索过滤器、地图或下拉菜单等一些元素，比其他元素需要更多的测试和创意。在Evolving Web，我们亲身体验过许多这样的挑战。在这篇文章中，我们将分享一些在解决棘手的无障碍访问问题时所采用的技巧。

无障碍测试工具的作用

为了符合WCAG AA指南并为所有人创造真正可用的体验，我们经常使用Axe DevTools、DubBot、SortSite和Siteimprove等工具。但在开发和质量保证阶段使用无障碍测试，通常会在流程后期才发现问题。因此，提前规划需要额外无障碍工作的功能非常重要。设计师、策略师、项目经理和质量保证专家都应从一开始就参与识别那些棘手的区域。

需要进行无障碍审查的功能

让巨型菜单实现无障碍访问

巨型菜单通常不仅仅包含链接列表 —— 它们可能有标题、图像、特色文章、简短说明，甚至像按钮或嵌入式搜索字段这样的交互式元素。但如果没有精心规划键盘和屏幕阅读器的使用体验，添加这些元素就会带来无障碍访问方面的挑战。

一、问题

当巨型菜单中添加了基本链接之外的内容时，通过键盘或屏幕阅读器导航的用户可能会遇到以下情况：

• 如果焦点管理不当，使用Tab键可能无法访问所有内容。
• 由于键盘陷阱循环，尤其是在错误使用tabindex的情况下，用户可能会被困在菜单中。
• 由于菜单部分没有清晰的提示，用户可能会迷失位置。

二、解决方案

• 为了使整个巨型菜单（而不仅仅是链接）实现无障碍访问，我们采用了一些特定的技巧：
• 确保打开的菜单内所有可聚焦的元素（链接、按钮、表单字段）都能按逻辑的Tab顺序访问。
• 菜单打开时，在父菜单项上使用aria-expanded="true"，并使用aria-controls引用子菜单容器。
• 在打开的菜单容器上添加aria-hidden="false"，以便屏幕阅读器知道菜单内容何时可用。
• 菜单打开时，将焦点移到面板内的第一个可聚焦项，并使用键盘监听器（如Escape键和箭头导航）让用户能够干净利落地退出或在各项之间移动。
• 确保菜单下拉项中的额外标题和按钮有可见的焦点样式

三、示例

ROM博物馆网站在“参观”标签下打开一个巨型菜单。该菜单显示三列内容：一列是像访客信息和无障碍访问这样的链接列表，一列是带有图像的博物馆地图与游览的可视化板块，还有一列是位置与停车信息。最右边是一个按日期显示开放时间的面板。该布局通过逻辑分组内容、支持清晰的Tab顺序，并提供可以与ARIA角色（如 aria-expanded 和 aria-hidden）结合使用的视觉结构，体现了无障碍访问的最佳实践，以确保屏幕阅读器的兼容性和流畅的键盘导航。
 

主导航下拉菜单的切换

在许多网站导航设计中，尤其是在桌面端，一级菜单项既作为链接，又作为下拉菜单的切换按钮。但将这两种功能结合在一个元素中，可能会让键盘用户和屏幕阅读器感到困惑。为了简化体验，我们通常会将带有子菜单的顶级菜单项设计为仅作为切换按钮，而不是链接。

一、问题

当一级菜单项既作为链接又作为下拉菜单的切换按钮时，可能会导致：

• 键盘用户的困惑：按Enter键是激活链接，还是打开下拉菜单？
• 根据标记结构的不同，屏幕阅读器的行为可能不一致。
• 尤其是在嵌套多级菜单时，难以清晰地管理焦点和aria状态。

二、解决方案

为了提供更清晰、更具无障碍性的体验，我们采取以下措施：

• 将父菜单项转换为仅用于切换子菜单可见性的按钮（或具有role="button"的链接），而不是导航到新页面。
• 使用下拉菜单中的第一个链接指向网站该部分的顶级页面（有时是该部分的着陆页）。
• 在切换按钮上使用aria-expanded="false"，并在下拉菜单打开时将其更新为true。
• 包含指向子菜单容器ID的aria-controls，以便屏幕阅读器获得更好的上下文信息。
• 确保子菜单默认隐藏（使用aria-hidden="true"和/或display: none），并在切换打开时显示。
• 将下拉菜单中的可聚焦项按逻辑Tab顺序排列，并允许仅使用键盘在所有项之间导航，然后再将焦点返回给父导航。

三、示例

我们在 佐治亚中心网站 上实现了这种模式，其中带有下拉菜单的顶级菜单项仅作为切换按钮。这使得键盘用户可以轻松探索所有子菜单项，而不会意外导航离开，也为屏幕阅读器用户提供了关于可展开内容的清晰提示。

 

让AJAX搜索过滤器对屏幕阅读器友好

我们喜欢使用AJAX让搜索过滤器感觉快速且响应灵敏 —— 内容无需重新加载页面即可立即更新。但虽然这改善了视觉和性能体验，却为屏幕阅读器用户带来了障碍，他们可能意识不到页面上有任何变化。

一、问题

• 当结果通过AJAX动态更新时，屏幕阅读器不会自动检测或提示这些变化：
• 用户可能不知道他们的过滤器选择是否起了作用。
• 结果部分可能在视觉上发生了变化，但非视觉用户却不会得到提示。
• 如果没有适当的提示，用户可能会感到迷失方向，或者认为过滤器“不起作用”。

二、解决方案

为了确保动态更新能传达给辅助技术，我们采取以下措施：

• 在更新的内容区域（如搜索结果或计数）周围添加aria-live="polite"区域。
• 应用过滤器后，添加一条清晰的消息，如“找到12个结果”。
• 使用JavaScript在AJAX请求完成后触发该区域的更新。
• 使用屏幕阅读器测试实现情况，确保实时区域确实能被读取。

三、示例

在 佐治亚格威内特学院 网站上，我们为需要页面重新加载的Drupal视图提供了屏幕阅读器提示。我们使用JavaScript将计数器附加到“跳转到主内容”链接上，以便在页面加载后首先读取该计数器。    

 

让自定义选择菜单实现无障碍访问

自定义样式的表单元素是设计师的最爱，尤其是当项目需要更具品牌特色或精致外观时。但用JavaScript替代原生表单控件（如 <select> 元素）会带来无障碍访问方面的挑战。虽然原生HTML元素默认是最具无障碍性的，但它们无法提供客户和设计师想要的设计灵活性。

一、问题

自定义选择菜单通常会：

• 如果没有完全实现，会破坏键盘导航（Tab、箭头键、Escape）。
• 缺乏适当的屏幕阅读器支持，尤其是在焦点提示、选择更改和打开/关闭状态方面。
• 让用户被困在字段内，或者在选择后无法正确返回焦点。

二、解决方案

为了在无障碍访问和视觉定制之间取得平衡，我们经常使用Select2 —— 一个模仿原生选择框但具有更好样式和功能支持的JavaScript库。

以下是我们的实现方法：

• 使用Select2的内置无障碍模式，包括ARIA支持和键盘导航模式。
• 根据需要自定义行为 —— 例如，确保选择后焦点返回到适当的元素，或者辅助技术能正确提示打开/关闭状态。
• 使用屏幕阅读器和键盘手动测试每个实现，以捕捉边缘情况。

让模态灯箱对键盘和屏幕阅读器友好

在展示视觉内容（如照片画廊、产品视图或展览亮点）时，设计师通常会依赖模态框或灯箱来创造沉浸式体验。虽然这些交互看起来很棒，但如果没有为键盘和屏幕阅读器用户精心实现，很容易成为无障碍访问的障碍。

一、问题

标准的灯箱/轮播库通常会：

• 不能正确地将键盘焦点限制在模态框内，允许用户通过Tab键进入隐藏的背景内容。
• 缺乏适当的ARIA角色或标签，因此屏幕阅读器可能无法识别模态框的上下文。
• 不能提供直观的键盘关闭模态框的方式。

二、解决方案

为了为图像画廊构建无障碍的模态框，我们使用Parvus，一个可定制的JavaScript灯箱。如果模态框用于显示内容或菜单，我们会用JavaScript创建一个自定义模态框。

在实现自定义模态框时，确保做到以下几点：

• 在模态框容器上添加role="dialog"和aria-modal="true"，以便屏幕阅读器知道它应该引起用户的注意。
• 确保模态框包含一个有标签的关闭按钮（如aria-label="关闭模态框"）。
• 模态框激活时，使用aria-hidden="true"隐藏背景内容，使屏幕阅读器无法访问。

三、示例

在 皇家安大略博物馆网站 上，我们使用Parvus库为展览创建模态灯箱。当用户点击图像上的信息图标时，会打开一个包含详细内容和图像的模态灯箱。

在模态框内：

• 键盘用户可以通过Tab键遍历所有交互式元素，包括文本、图像和关闭按钮。
• 在最后一项之后，焦点会循环回到模态框内的第一项。
• 用户可以按Escape键关闭灯箱，并从离开的位置继续导航。

防止滑块中的键盘陷阱

滑块和轮播通常用于突出展示特色内容 —— 尤其是在页面的英雄区域或产品展示中。但使用Swiper.js等库时，可能会引入键盘无障碍访问问题，使用户被困在滑块中无法退出。

一、问题

Swiper的默认循环模式会复制幻灯片以实现无限滚动。这对键盘用户会产生意想不到的后果：

• 所有复制的幻灯片元素都保留在DOM中且可聚焦，即使它们不可见。
• 这会造成键盘陷阱，用户会在复制的幻灯片中不断按Tab键，永远无法退出滑块。

二、解决方案

为了解决这个问题，我们使用一个自定义的JavaScript函数来控制滑块内哪些元素可以获得焦点：

• 我们动态地将所有不可见幻灯片的tabindex设置为"-1"，仅对当前可见的幻灯片移除该设置。
• 我们使用Swiper的事件监听器（如on: slideChange等）检测幻灯片的变化，并实时更新可聚焦元素。
• 这确保只有可见的幻灯片可以通过键盘访问，用户可以按Tab键前进到滑块外的内容。
• 我们还使用实际内容测试滑块（尤其是在幻灯片内使用链接或按钮时），以确保屏幕阅读器和键盘用户能够无困惑地进行交互。

三、示例

在一个项目中，我们使用 Swiper库 实现了一个循环滑块，在每个幻灯片中展示链接文章和故事。然而，启用循环模式后，所有幻灯片链接都保持可聚焦状态 —— 即使不在屏幕上 —— 造成了无限的Tab循环。为了解决这个问题，我们添加了自定义JS，使只有可见元素可聚焦。

这个简单的调整让键盘用户可以一次性通过滑块，然后继续浏览页面的其他部分。

 

以无障碍方式处理非必要的SVG地图

SVG地图可以是一种视觉丰富、可点击的方式，帮助用户探索内容 —— 尤其是对于区域目录或过滤工具。但当地图作为增强功能而非必要的导航工具使用时，它们可能会带来比解决的问题更多的无障碍访问挑战。

一、问题

基于SVG的地图通常会：

• 包含许多需要适当ARIA标签和键盘支持的交互式区域。
• 本身不支持键盘导航，需要大量的脚本编写来管理焦点、交互性和屏幕阅读器兼容性。

二、解决方案

当地图对用户体验并非必要时，我们可以：

• 使用aria-hidden="true"或类似技术将地图对辅助技术隐藏。
• 提供一个完全无障碍的替代方案 —— 如结构化列表或下拉菜单。

三、示例

在加拿大药品管理局网站上，我们使用了一个基于SVG的区域地图，帮助用户按地区查找项目。然而，要使每个区域完全无障碍（标签、焦点控制、键盘行为），需要进行大量的自定义开发。相反，我们提供了一个“查看数据表”的链接，以结构化、无障碍的方式展示所有相同的内容。

让图标对屏幕阅读器和编辑人员有意义

图标在现代网站上随处可见。无论是用于分隔密集内容、快速传达含义，还是支持品牌的视觉语言，它们都是有价值的设计工具。但当图标作为传达重要信息的唯一方式时，它们就成为了内容，而不仅仅是装饰。这意味着它们必须具有无障碍性。

一、问题

作为内容使用的图标需要：

• 为屏幕阅读器提供有意义的描述标签。
• 结构合理，以便内容编辑人员可以在内容管理系统（CMS）中轻松管理它们。
• 避免重复内容或因视觉/文本提示冲突而造成混淆。
• 如果处理不当，屏幕阅读器可能会完全跳过图标 —— 或者提示一些通用的内容，如“图像”或“图形”。

二、解决方案

为了确保图标对内容作者具有无障碍性和可管理性，我们采取以下措施：

• 使用视觉上隐藏的HTML元素为每个图标配对仅屏幕阅读器可见的文本（如“无麸质”）
• 允许编辑人员直接在CMS中添加或管理此文本，而不是硬编码。
• 使用ARIA角色，使屏幕阅读器将图标解释为标签，而不是装饰性图形。

三、示例

在佐治亚大学（UGA）网站上，我们在餐厅菜单上实现了这个解决方案，其中图标传达重要的饮食信息。通过构建包含隐藏描述性文本的标记结构，并在CMS中启用编辑控制，我们使界面既具有无障碍性，又能持续更新内容。
 

确保暗模式下的无障碍焦点状态

暗模式已成为现代网站流行的设计选择。它可以减少眼睛疲劳，满足用户偏好，并营造时尚的美感。但启用暗模式主题在无障碍访问方面增加了额外的复杂性 —— 特别是在颜色对比度和焦点可见性方面。

一、问题

• 在亮模式下通过的颜色对比度在暗模式下可能不通过，尤其是在悬停或聚焦时。
• 焦点指示器在深色背景下可能会消失或变得过于微妙。
• 如果焦点样式没有在不同主题下进行测试，键盘用户可能会失去导航的视觉提示。

二、解决方案

• 在亮模式和暗模式下测试所有状态变化（默认、悬停、聚焦、激活）。
• 使用符合WCAG的颜色对比度：
  • 文本为4.5:1
  • 用户界面组件（边框、轮廓、焦点环）为3:1
• 自定义样式，确保暗模式下有可见的焦点指示器（如轮廓、阴影）。

要点总结：团队应关注的事项

无论你是开发人员、设计师还是项目经理，以下几点需要牢记：

• 在开发早期检查键盘和屏幕阅读器支持，特别是对于交互式元素。
• 不要仅仅依赖测试工具。结合用户场景进行手动测试是关键。
• 寻找替代方案和备用方案 —— 例如提供地图内容的文本版本或非动态的过滤器选项。

结论

无障碍访问不仅仅是勾选清单或遵循规则 —— 而是创造对每个人都有效的数字体验。通过在流程早期识别棘手的功能，你的团队可以更好地进行规划、评估和设计，将包容性纳入考虑，减少后期修复的需求，提高所有人的可用性。

在Evolving Web，我们专注于帮助组织直接应对这些挑战。从无障碍审计到自定义组件设计和战略指导，我们支持团队构建不仅合规而且真正具有无障碍性的网站。如果你想改善网站的无障碍性或解决特定挑战，请与我们联系。