星期五是一天的结束。 坏消息总是在星期五结束时出现。
您将要离开办公室，“ dzin”一封有关下一次重组的新信件刚刚到达邮件中。
谢谢xxxx，yyy从今天起您将向zzzz报告
...
休团队将为残疾人提供我们的产品。
哦，不！ 为什么我应该得到它？ 他们要我离开吗？ 调整一下忘恩负义的辛勤工作，并尝试纠正其他人的错误。 这可能是一个失败...
那是几年前的可访问性。 一些穷人承担了“清理”用户界面的工作，以尝试使残疾人可以访问它。
这实际上的含义很模糊-可能是如果您可以看到焦点指示符并使用选项卡在字段中移动，有一些替代文本和几个字段说明，则可以认为您的应用程序可用...
但是突然之间，“虫子”开始以雪崩的速度繁殖。
不同的屏幕阅读器和浏览器的行为完全不同。
用户抱怨该应用程序不适合使用。
一处纠正错误后，另一处出现了另一处。
而且，仅更改和修复用户界面错误就需要付出巨大的努力。
我在那里 我幸存了下来，但是我们没有“成功”-从技术上讲，我们进行了很多工作，在字段，角色上添加了很多描述，并达到了一定程度的遵从性，但没人满意。 用户仍然抱怨他们无法在应用程序中导航。 经理仍然抱怨不断出现错误。 工程师抱怨问题的表述不正确，而没有一个明确定义的“正确”解决方案在所有情况下都可行。
在我理解可访问性的过程中，出现了一些明显的坦白时刻。
也许首先是这样的理解，即很难在最终产品上添加可访问性功能。 而且，要说服经理人这是非常困难的，就更难了！ 不，不仅仅是“添加了一些标签”，而且用户界面也可以正常工作。 不，不可能在三个星期内完成，即使三个月也不够。
当我亲眼看到盲用户如何实际使用我们的应用程序时，我的下一个关键时刻到了。 这与查看错误消息有所不同。
我将一遍又一遍地回到这个问题上，但是几乎所有关于人们如何使用我们的应用程序的“假设”都是错误的。
使用
Tab/Shift+Tab键浏览复杂的用户界面很糟糕！ 需要更好的东西。 键盘快捷键，标题。
更改UI时失去焦点不是大问题吗？ 再想想-这真是令人困惑。
我继续进行了一段时间的各种项目工作，然后我们开始了一个新项目，该项目具有复杂的用户界面和清晰的安装，以便最终获得正确的可访问性。
因此，我们退后了一步，研究了如何以不同的方式实现它并取得成功，从而使工作过程本身不会感到无聊！
我们很快得出了一些结论：
- 我们不希望开发用户界面的人陷入aria标签/角色，自然而然地陷入组件的HTML结构。 我们需要为他们提供正确的组件，这些组件中开箱即用地实现了可访问性。
- 可用性==易于使用-即 这不仅是一项技术任务。 我们需要更改整个设计过程，并确保在设计用户界面之前考虑了可访问性并进行了讨论。 首先必须考虑用户如何找到任何功能，他们将如何移动以及如何从键盘上单击鼠标的“右键”。 可访问性应该是设计过程中不可或缺的一部分-对于某些用户而言，它不仅仅是应用程序的外观。
- 从一开始，我们就希望从盲人和其他残障用户那里收到有关应用程序易用性的反馈。
- 我们需要真正好的方法来捕获可访问性回归。
好吧，从工程学的角度来看，第一部分听起来很有趣-体系结构的开发和组件库的实现。 确实是这样。
退后一步，查看
ARIA示例并将其视为设计问题，而不是“适应”问题，我们介绍了一些抽象概念。 该组件具有一个“结构”（由HTML元素组成）和一个“行为”（与用户交互的方式）。 例如，在下面的代码片段中，我们有一个简单的无序列表。 在列表中添加“行为”时，将添加适当的角色，使其像列表一样起作用。 同样，我们为菜单做。
实际上，不仅在此处添加了角色，而且还添加了用于键盘导航的事件处理程序。
它看起来已经更加整洁了。 如果我们能够将它们之间完全分开，那么结构的创建方式就无关紧要，我们可以将“行为”应用于它并获得正确的可访问性。
实际上，可以在
https://stardust-ui.imtqy.com/react/上看到它
-React UX库，从一开始就考虑到可访问性而设计和实现。
第二部分-围绕设计的方法和流程的变化最初使我感到恐惧：试图推动组织变革的谦虚工程师并不总是能以圆满结束，但是事实证明，这是我们对流程做出重大贡献的最有趣的领域之一。 简而言之，我们执行以下过程：由一个团队开发新功能，然后由我们的经理团队分析/迭代该提议，然后在获得批准后，通常将设计移交给工程师团队。 在这种情况下，工程团队实际上“拥有”了可用性功能，因为它应该消除与之相关的所有问题。
最初，这是一项相当困难的工作-解释可访问性和可用性是密不可分的，并且必须在设计阶段完成此操作，否则将导致较大的更改和某些角色的重新定义。 但是，在管理层和主要参与者的支持下，我们提出了这个想法并将其付诸实践，以便设计在提交给管理层之前通过可访问性和可用性的测试。
这些评论对每个人都非常有价值-太棒了，就像一个共享知识/传输有关用户如何与Web应用程序交互的信息的练习一样，我们在构建用户界面之前确定了用户界面的许多问题区域，当前，不仅在视觉上，而且在设计的行为方面，都有更好的规范。 真正的讨论是关于技术方面和交互的有趣，充满活力，热情的讨论。
如果在与我们的这些（或后续）会议中会有盲人用户和残疾用户，我们可以使这项工作变得更好，这很难组织，但是现在我们确实与盲人的本地组织以及公司合作提供外部测试以验证开发早期阶段的工作流程-在组件级别和工作流程级别。
工程师现在拥有相当详细的规范，可用于实施的可用组件以及检查执行流程的方法。 在某种程度上，经验告诉我们我们一直想念的东西-我们如何才能停止回归。 同样，人们可以使用集成或端到端测试来测试我们需要的功能，以检测交互和线程的变化（包括视觉和行为）。
视觉回归的定义是一个相当明确的任务；除了在使用键盘导航时检查焦点是否可见之外，几乎没有什么可以添加到此过程中的。 更有趣的是用于可访问性的两种相对较新的技术。
- Accessibility Insights是可以在浏览器中以及在构建/测试周期内运行以识别问题的一组工具。
- 检查屏幕阅读器的正确操作是一项特别困难的任务。 通过将可访问性DOM引入可访问性 ，我们终于有机会在可访问性方面对应用程序进行快照，这与我们进行视觉测试的方式非常相似，并对其进行回归检查。
因此，在故事的第二部分中，我们从编辑HTML代码转变为在更高的抽象级别上工作，更改了设计开发流程并引入了严格的测试。 新的流程，新的技术和新的抽象层次完全改变了可访问性的概念，以及在此领域中工作的意义。
但这仅仅是开始。
下一个“理解”是盲人用户推广尖端技术-他们不仅从我们先前描述的更改中获得最大的收益，而且在ML / AI的帮助下使新方法和新想法成为现实。 例如，沉浸式阅读器技术使用户可以更轻松地呈现文本。 它可以大声朗读，句子结构在语法上分开，甚至单词的含义也以图形方式显示。 这绝对不符合对“使它可用”的旧理解-它是一种可用性功能，将对所有人都有帮助。
借助ML / AI，崭新的交互和工作方式正在兴起，我们很高兴成为这一高级途径中下一步的一部分。 创新归因于思维方式的改变-人类已经存在了几千年，汽车已经有数百年了，网站已经有几十年了，智能手机甚至更小，技术必须适应人们的需求，反之亦然。
PS：本文翻译时与原始译本有一些出入。 作为本文的合著者，我同意与休之间的这些题外话。