好，更好，最好：解开可访问模式的复杂世界

已发表: 2022-03-10
快速总结↬在可访问性方面，我们如何知道哪些模式是好的、更好的、最好的？ 使用已建立的模式/库还是创建新模式/库更好？ 有了无数的选择，我们很快就会陷入关于这个话题的混乱网络。

马克·贝尼奥夫 (Marc Benioff) 令人难忘地指出，科技行业唯一不变的就是变化。 我在科技行业工作了超过 15 年，我可以证实这一点。 科技恐龙同胞可以证明，早期网络的工作方式与我们许多人甚至想象的完全不同。

虽然技术行业的这种不断变化带来了我们今天看到的创新和进步，但它也引入了选择的概念。 虽然选择——从表面上看——似乎是一种天生的积极事物，但它并不总是等于彩虹和玫瑰。 技术变革的涌入也带来了编码语言的分裂和编程“热”的永无止境的味道。 有时，这种丰富的选择会变成过度选择——一种经过充分研究的认知障碍，人们由于有太多选择而难以做出决定。

在本文中，我们将尝试解开可访问模式的复杂世界——一步一步。 我们将通过回顾当前可访问的模式和库来开始，然后我们将考虑我们的一般模式需求和潜在的限制，最后，我们将通过一系列批判性思维练习来学习如何更好地评估可访问性模式。

我们编织了多么纠结的网

Overchoice 已经渗透到技术的各个方面，包括我们用来构建数字创作的模式和库——从简单的复选框到复杂的动态模式，以及介于两者之间的一切。 但是当有这么多选择时，我们怎么知道哪个模式或库是正确的呢？ 使用用户每天遇到的既定模式/库会更好吗？ 还是创建全新的模式以获得更愉快的用户体验更好？

有了无数的选择，我们很快就会因过多的选择而瘫痪。 但是，如果我们退后一步，考虑一下为什么我们首先要构建我们的数字产品（即最终用户），那么选择可以为最多的人增加最大价值的模式或库是否有意义？ ?

如果您认为选择模式或库已经是一个令人生畏的过程，那么这可能是您开始担心的地方。 但不必担心——选择一个可访问的模式/库不是火箭科学。 就像技术中的其他一切一样，这个旅程始于一点点知识、大量的试验和错误，以及对不存在适合每个用户、情况或框架的完美模式/库的理解。

我怎么知道这个？ 好吧，在过去的五年里，我一直在研究、构建和测试不同类型的可访问模式，同时研究 A11y 样式指南、Deque 的 ARIA 模式库，并评估流行的 SVG 模式。 但我也审查了每个可以想象的框架/平台上的许多客户端模式和库。 在这个时间点上，我可以毫不犹豫地说，当你观察足够长的时间时，模式可访问性就开始发展。 虽然偶尔会有不惜一切代价避免的模式，但它并不总是那么明确。 谈到可访问性，我认为大多数模式都属于好、更好、最好的渐变。 困难的部分是知道哪种模式属于哪个类别。

跳跃后更多！ 继续往下看↓

批判性地思考模式

那么，在可访问性方面，我们如何知道哪些模式是好的、更好的、最好的呢？ 这取决于。 数字可访问性社区经常引用的这句话不是逃避，而是“我们需要更多背景才能给你最好的答案”的简写。 但是，上下文并不总是很清楚，因此在构建和评估模式的可访问性时，我提出的一些基本问题包括：

  • 是否已经有我们可以使用的既定可访问模式？
  • 我们支持哪些浏览器和辅助技术 (AT) 设备？
  • 是否有任何框架限制或其他集成/因素需要考虑？

当然，您的具体问题可能与我的不同，但关键是您需要在评估模式时开始使用您的批判性思维技能。 您可以通过首先观察、分析然后对每个模式的可访问性进行排名，然后再做出最终决定来做到这一点。 但在我们开始之前，让我们先深入研究一下最初的问题。

是否已经建立了可访问的模式？

为什么似乎每个新框架，我们都会得到一套全新的模式？ 这种不断地用新的模式选择重新发明轮子可能会使开发人员感到困惑和沮丧，特别是因为通常没有必要这样做。

不相信我？ 好吧，这样想：如果我们订阅原子设计系统，我们就会明白几个小的代码“原子”组合在一起可以创建一个更大的数字产品。 但在科学界，原子并不是生命中最小的组成部分。 每个原子由许多亚原子粒子组成，如质子、中子和电子。

同样的逻辑也可以应用于我们的模式。 如果我们更深入地研究现有各种框架中可用的所有模式，核心亚原子结构基本上是相同的，而不管使用的实际编码语言如何。 这就是为什么我欣赏具有可访问模式的流线型编码库，我们可以根据技术和设计需求进行构建。

注意：除了 Smashing Magazine 最近发布的可访问模式列表（以及文章末尾的更详细的模式和库列表）之外，一些著名的来源包括 Inclusive Components、Accessible Components 和 Gov.UK Design System .

我们支持哪些浏览器和辅助技术 (AT) 设备？

在研究了一些可能有效的基本模式之后，我们可以继续讨论浏览器和辅助技术 (AT) 设备支持的问题。 就其本身而言，浏览器支持不是开玩笑。 当您将 AT 设备和 ARIA 规范添加到组合中时，事情开始变得棘手……并非不可能，只是需要更多的时间、精力和思考过程来解决所有问题。

但这并不全是坏消息。 有一些很棒的资源，例如 HTML5 Accessibility 和 Accessibility Support，可以帮助我们更好地了解当前的浏览器 + AT 设备支持。 这些网站概述了可用的不同 HTML 和 ARIA 模式子元素，包括开源社区测试，并提供了一些模式示例——适用于桌面和移动浏览器/AT 设备。

是否有任何框架限制或其他集成/因素需要考虑？

一旦我们选择了一些可访问的基本模式并考虑到浏览器/AT 设备支持，我们就可以继续围绕模式及其环境提出更细粒度的上下文问题。 例如，如果我们在内容管理系统 (CMS) 中使用模式或考虑遗留代码，则会存在某些模式限制。 在这种情况下，少数模式选择可以很快减少到一两个。 另一方面，一些框架更宽容，更愿意接受任何模式，因此我们可以少担心框架限制，而更多地专注于做出我们可以做出的最容易获得的模式选择。

除了到目前为止我们讨论的所有内容之外，在选择模式时还有许多其他考虑因素需要权衡，例如性能、安全性、搜索引擎优化、语言翻译、第三方集成等等。 这些因素无疑会影响您的可访问模式选择，但您还应该考虑创建内容的人。 您选择的可访问模式必须以足够健壮的方式构建，以处理围绕编辑器生成和/或用户生成的内容的任何潜在限制。

评估可访问性模式

代码往往胜于雄辩，但在我们开始讨论所有这些之前，请快速注意以下模式示例并不是每种情况下唯一可用的模式，也不是该组中被认为是“最佳”的模式中的最佳选择整个世界的可访问模式。

对于下面的模式演示，我们应该想象一个假设的情况，在这种情况下，我们将每组模式与它们自己进行比较。 虽然这不是一个现实的情况，但通过这些批判性思维练习并评估可访问性模式应该可以帮助您在现实世界中遇到模式选择时做好准备。

可访问的按钮模式

我们将审查的第一组可访问性模式几乎在每个网站或应用程序中无处不在：按钮。 第一个按钮模式使用 ARIA 按钮角色来模拟按钮，而第二个和第三个按钮模式使用 HTML <button>元素。 第三种模式还添加了aria-describedby和 CSS 以在视觉上隐藏事物。

请参阅 Carie Fisher 的 Pen [Accessible Button Patterns](https://codepen.io/smashingmag/pen/KKNEjKR)。

请参阅 Carie Fisher 的 Pen Accessible Button Patterns。

好： role="button"

 <a role="button" href="[link]">Sign up</a>

更好： <button>

 <button type="button">Sign up</button>

最佳： <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

虽然第一个模式乍一看似乎很简单，但它们确实引发了一些可访问性问题。 例如，在第一个按钮模式中，我们看到 ARIA role="button"用于“好”模式而不是 HTML <button>元素。 从可访问性的角度考虑，由于我们知道 HTML <button>元素是在 HTML4 中引入的，我们可以合理地推测它被所有主要浏览器的最新版本完全支持，并且可以很好地与大多数 AT 设备配合使用。 但是，如果我们更深入地研究 ARIA role="button" 的可访问性支持，我们会从辅助技术的角度看到一点优势，而 HTML <button>元素缺少浏览器 + AT 覆盖的某些区域，尤其是当我们考虑语音控制支持。

那么，为什么 ARIA 模式不在“更好”类别中呢？ ARIA 不是让它更易于访问吗？ 没有。 事实上，在这种情况下，可访问性专家经常背诵 ARIA 的第一条规则——不要使用 ARIA。 这是一种开玩笑的说法，即尽可能使用 HTML 元素。 ARIA 确实很强大，但在坏人手中，它弊大于利。 事实上，WebAIM Million 报告指出，“有 ARIA 的页面平均比没有的页面多 60% 的错误。” 因此，您在使用 ARIA 时必须知道自己在做什么。

在这种情况下使用 ARIA 的另一个问题是，我们需要为role="button"模式构建我们需要的按钮功能，而该功能已经预先烘焙到<button>元素中。 考虑到<button>元素也有 100% 的浏览器支持并且是一个易于实现的模式，在评估前两个模式时，它在层次结构中略微领先。 希望这种比较有助于打破添加 ARIA 使模式更易于访问的神话——通常情况恰恰相反。

第三个按钮模式显示了 HTML <button>元素以及aria-describedby链接到一个 ID 元素，该 ID 元素在 CSS 中隐藏。 虽然这种模式稍微复杂一些，但它通过在按钮和用途之间创建关系，在上下文方面增加了很多。 如果有疑问，只要我们可以为情况添加更多上下文就更好了，因此我们可以假设如果编码正确，仅比较这些特定按钮模式时，它是最好的模式。

可访问的上下文链接模式

我们将回顾的第二组模式是上下文链接。 这些模式有助于向 AT 用户提供比屏幕上可见的信息更多的信息。 第一个链接模式利用 CSS 以可视方式隐藏附加的上下文信息。 而第二个和第三个链接模式将 ARIA 属性添加到组合中：分别为aria-labelledby和aria-label 。

请参阅 Carie Fisher 的 Pen [Accessible Link Patterns](https://codepen.io/smashingmag/pen/VwmRJYv)。

请参阅 Carie Fisher 的 Pen Accessible Link Patterns。

好： visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

更好： visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

最佳： aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

虽然所有三种上下文链接模式看起来都一样，但当我们检查代码或使用 AT 设备测试它们时，会有一些明显的差异。 第一种模式使用 CSS 技术为有视力的用户隐藏内容，但仍将隐藏的内容呈现给无视力的 AT 用户。 虽然这种技术在大多数情况下都可以工作，但链接和附加信息之间并没有形成真正的关系，所以这种联系充其量只是试探性的。 因此，第一个链接模式是一个不错的选择，但不是三者中最健壮的链接模式。

接下来的两个链接模式评估起来有点棘手。 根据 W3C 的 ARIA 规范，“ aria-label的目的与 aria aria-labelledby的目的相同。 它为用户提供了一个可识别的对象名称。” 因此，理论上，这两个属性应该具有相同的基本功能。

然而，规范还指出，在决定向用户传达哪个可访问名称时，用户代理优先于aria-labelledby而非aria-label 。 研究还显示了围绕自动翻译和 aria-label 属性的问题。 所以这意味着我们应该使用aria-labelledby ，对吗？

嗯，没那么快。 同样的 ARIA 规范继续说“如果界面无法在屏幕上显示可见标签（或者如果可见标签不是所需的用户体验），作者应该使用aria-label并且不应该使用aria-labelledby 。” 谈论混乱 - 那么我们应该选择哪种模式？

如果我们有大规模的翻译需求，我们可能会决定改变视觉方面并写出显示完整上下文的链接（例如“阅读更多关于这个很棒的东西”）或决定使用aria-labelledby 。 但是，假设我们没有大规模的翻译需求，或者可以以合理/可访问的方式解决这些需求，并且我们不想改变视觉 - 那么怎么办？

基于当前的 ARIA 1.1 建议（承诺在 ARIA 1.2 中翻译 aria-label），再加上aria-label相对于aria-labelledby对开发人员来说更容易实现这一事实，我们可以决定对aria-label进行加权aria-labelledby在我们的模式评估中。 这是一个明显的例子，说明上下文在我们可访问的模式选择中占很大比重。

可访问<svg>模式

最后，但同样重要的是，让我们研究一组 SVG 图像模式的可访问性。 SVG 是代码的可视化表示，但仍然是代码。 这意味着 AT 设备可能会跳过非装饰性 SVG 图像，除非将role="img"添加到模式中。

假设以下 SVG 模式本质上是信息性的，则每个都包含一个role="img" 。 第一个 SVG 模式将<title>和<text>与 CSS 结合使用，以在视觉上对有视力的用户隐藏内容。 接下来的两个 SVG 模式涉及<title>和<desc>元素，但在最后一个模式中添加了aria-labelledby属性。

请参阅 Carie Fisher 的 Pen [Accessible SVG Patterns](https://codepen.io/smashingmag/pen/poNYXvK)。

请参阅 Carie Fisher 的 Pen Accessible SVG Patterns。

好： role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

更好： role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

最佳： role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

让我们先看看使用<title>和<text>以及视觉隐藏的 CSS 的第一个模式。 与以前在模式中可见隐藏的文本不同， <title>和<text>元素之间存在固有的关系，因为它们被分组在同一个 SVG 元素保护伞下。 但是，这种关系并不是很牢固。 事实上，如果你回顾我对 SVG 模式的研究，我们会发现 8 个浏览器/AT 组合中只有 3 个听到了完整的信息。 （注：猪图案#1 等同于灯泡图案#7。）

尽管工作中的 W3C SVG 规范将<text>元素定义为“由文本组成的图形元素……要绘制的字符表示为字符数据，但这是真的。 因此，视障人士可以轻松访问 SVG 内容中的文本数据。” 第一个模式是可以的，但我们可以做得更好。

第二个模式删除<text>元素并用<desc>元素替换它。 W3C SVG 规范指出：

“ <title>子元素代表元素的短文本替代项......而<desc>元素代表元素的更详细的文本信息，例如描述。”

这意味着 SVG 中的<title>和<desc>元素可以与传统上在<img>元素中找到的图像替代文本和长描述选项类似地使用。 将<desc>元素添加到第二个 SVG 后，我们看到类似的浏览器/AT 支持，8 种组合中有 3 种听到了完整的消息。 （注意：猪模式#2 等同于灯泡模式#10。）虽然这些测试结果似乎反映了第​​一个模式，但这种模式进入“更好”类别的原因是它更容易实现代码-明智的做法是影响更多的 AT 用户，因为它适用于 JAWS、VoiceOver 桌面和 VoiceOver 移动设备，而第一个模式支持不太流行的浏览器/AT 组合。

第三个模式再次使用<title>和<desc>元素，但现在添加了一个aria-labelledby和 ID。 根据相同的 SVG 测试，添加这段额外的代码意味着我们可以完全支持 8 种浏览器/AT 组合中的 7 种。 （注意：猪模式#3 相当于灯泡模式#11。）在三种 SVG 模式中，第三种模式是“最好的”，因为它支持最多的 AT 设备。 但是这种模式在使用某些浏览器/AT 组合时确实存在缺陷。 您将听到此模式的重复图像标题/描述内容。 虽然对用户来说可能很烦人，但我认为听到重复的内容通常比根本不听要好。

结束的想法

虽然我们当然都重视科技领域的选择，但我想知道我们是否已经到了一个时间点，即过多的选择让我们对下一步做什么感到瘫痪和困惑？ 在选择可访问模式方面，我们可以就模式/库选项、浏览器/AT 设备支持、框架限制等提出直截了当的问题。

有了正确的数据，这些问题就很容易回答了。 然而，当我们超越模式并真正考虑使用它们的人时，它变得有点复杂。 那时我们才意识到我们的选择对用户成功能力的影响。 正如 George Dei 教授雄辩地指出：

“包容并没有将人们带入已经存在的事物中——它正在为每个人创造一个新的空间，一个更好的空间。”

通过花更多的时间批判性地思考模式并选择最容易获得的模式，我们无疑将创造一个更具包容性的空间来接触更多的用户——按照他们的条件。

相关资源

工具

  • 辅助功能支持，Michael Fairchild，a11ysupport.io
  • HTML5 可访问性，史蒂夫·福克纳

模式库

  • 无障碍项目
  • 无障碍风格指南
  • 无障碍组件，Scott O'Hara
  • 可访问drag-and-drop列表重新排序插件，Harris Schneiderman
  • Deque 的 ARIA 模式库
  • Deque 的可访问 React 库
  • GOV.UK 设计系统
  • 包容性组件，Heydon Pickering
  • 美国网页设计系统 (USWDS)
  • 无障碍网页教程