星期五是工作日的结束时间。 坏消息总是在周五工作日结束时传来。
您即将离开办公室，一封关于另一次重组的新信刚刚寄到。
谢谢xxxx，yyy从今天起你举报zzzz
...
休的团队将确保残疾人士也能使用我们的产品。
不好了！ 为什么这是我应得的？ 他们要我离开吗？ 让自己做好吃力不讨好的努力，并努力纠正别人的错误。 这绝对是失败的...
这是几年前的可用性。 一些可怜的人被赋予了“清理”用户界面的工作，试图让残疾人可以使用它。
这实际上意味着什么是相当模糊的 - 大概如果您可以通过字段看到焦点指示器和选项卡，有一些替代文本和几个字段描述，那么就会认为您的应用程序是可访问的......
但突然之间，“虫子”开始以雪崩的速度繁殖。
各种屏幕阅读器（工程。 屏幕阅读器）和浏览器的行为完全不同。
用户抱怨该应用程序无法使用。
一旦一个地方的错误被纠正，另一个地方就会出现另一个错误。
仅仅改变和纠正用户界面错误就需要付出巨大的努力。
我在那里。 我活了下来，但我们并没有“成功”——技术上我们清理了很多，添加了很多字段描述、角色，并实现了一定程度的合规性，但没有人高兴。 用户仍然抱怨他们无法导航该应用程序。 经理仍然抱怨不断出现错误。 工程师们抱怨说，问题的提出不正确，没有明确定义的适用于所有情况的“正确”解决方案。
在我了解可访问性的过程中，有一些绝对令人大开眼界的时刻。
也许第一个是认识到在成品上添加辅助功能是很困难的。 更难让经理们相信这是极其困难的！ 不，这不仅仅是“添加一些标签”，用户界面就能正常工作。 不，这不可能在三周内完成，甚至三个月也不够。
当我亲眼目睹盲人用户如何实际使用我们的应用程序时，我的下一个关键时刻到来了。 这与查看错误消息非常不同。
我会一次又一次地回顾这一点，但几乎所有关于人们如何使用我们的应用程序的“假设”都是错误的。
使用按键导航复杂的用户界面 Tab/Shift+Tab – 这太糟糕了！ 我们需要更好的东西。 键盘快捷键、标题。
更改 UI 时失去焦点并不是一个大问题，不是吗？ 让我们再想一想——这太令人困惑了。
我继续，在不同的项目上工作了一段时间，然后我们开始了一个新项目，具有复杂的用户界面和清晰的安装，这次终于获得了可访问性。
因此，我们退后一步，研究如何以不同的方式实施这一点并取得成功，并使过程不再那么无聊！
很快我们就得出了一些结论：
- 我们不希望开发用户界面的人弄乱 aria 标签/角色，当然还有组件的 HTML 结构。 我们需要为他们提供正确的组件，以实现开箱即用的可访问性。
- 可访问性==易于使用——即这不仅仅是一个技术挑战。 我们需要改变整个设计流程，并确保在 UI 设计开始之前考虑并讨论可访问性。 您需要尽早考虑用户将如何发现任何功能、他们将如何导航以及如何通过键盘右键单击。 可访问性应该是设计过程中不可或缺的一部分 - 对于某些用户来说，它不仅仅是应用程序的外观。
- 从一开始，我们就希望获得盲人和其他残疾人用户对应用程序易用性的反馈。
- 我们需要非常好的方法来捕捉可访问性回归。
嗯，从工程的角度来看，第一部分听起来很有趣——开发一个架构并实现一个组件库。 确实如此。
退一步看 通过将其视为一个设计问题而不是“适应”问题，我们引入了一些抽象。 组件具有“结构”（由 HTML 元素组成）和“行为”（它如何与用户交互）。 例如，在下面的代码片段中，我们有一个简单的无序列表。 通过添加“行为”，相应的角色将被添加到列表中，使其像列表一样工作。 我们对菜单也做了同样的事情。
事实上，这里不仅添加了角色，还添加了键盘导航的事件处理程序。
这看起来更整洁。 如果我们能够在它们之间得到清晰的分离，那么结构是如何创建的并不重要，我们可以对其应用行为并获得正确的可访问性。
您可以在以下位置查看此操作的实际效果： – 用户体验库 ，其设计和实施从一开始就考虑到了可访问性。
第二部分——改变设计的方法和流程最初让我感到害怕：试图推动组织变革的低级工程师并不总是有好结果，但事实证明这是我们为流程做出重大贡献的最有趣的领域之一。 简而言之，我们的流程如下：新功能将由一个团队开发，然后我们的领导团队将审查/迭代提案，然后，一旦获得批准，设计通常会移交给工程团队。 在这种情况下，工程团队实际上“拥有”可访问性功能，因为他们有责任解决与之相关的任何问题。
一开始，要解释可访问性和可用性是密不可分的，并且必须在设计阶段完成，这是一项相当困难的工作，否则会导致一些角色的重大变化和重新定义。 然而，在管理层和关键参与者的支持下，我们采纳了这个想法并将其付诸实施，以便在将设计提交给管理层之前对其可访问性和可用性进行测试。
这个反馈对每个人来说都非常有价值 - 作为关于用户如何与 Web 应用程序交互的知识共享/交流的练习，我们在构建之前识别了许多 UI 问题领域，现在的开发团队有了更好的规范不仅是视觉方面，还包括设计的行为方面。 真正的讨论是关于技术方面和交互的有趣、充满活力、热情的讨论。
如果我们在这些（或后续）会议上有盲人和残疾用户，我们可以做得更好 - 这很难组织，但我们现在确实与当地盲人组织和公司合作，他们提供外部测试以在早期验证执行流程开发——组件级别和执行流程级别。
工程师现在拥有相当详细的规范、可用于实施的可用组件以及验证执行流程的方法。 经验告诉我们的部分内容是我们一直缺失的——如何阻止倒退。 同样，人们可以使用集成或端到端测试来测试功能，我们需要检测交互和执行流程（视觉和行为）的变化。
确定视觉回归是一项明确定义的任务，除了检查使用键盘导航时焦点是否可见之外，几乎没有什么可以添加到该过程中。 更有趣的是两种相对较新的可访问性技术。
- 是一组工具，可以在浏览器中运行，也可以作为构建/测试周期的一部分来识别问题。
- 验证屏幕阅读器是否正常工作是一项特别具有挑战性的任务。 随着访问权限的引入 可访问性 DOM，我们终于能够拍摄应用程序的可访问性快照，就像我们在视觉测试中所做的那样，并测试它们的回归。
因此，在故事的第二部分中，我们从编辑 HTML 代码转向更高抽象级别的工作，改变了设计开发流程并引入了彻底的测试。 新流程、新技术和新的抽象层次彻底改变了可访问性的格局以及在这个领域工作的意义。
但这只是一个开始。
下一个“理解”是盲人用户正在推动尖端技术——他们不仅是我们前面描述的变化的最大受益者，而且是机器学习/人工智能带来的新方法和想法的受益者。 例如，沉浸式阅读器技术可以让用户更轻松、清晰地呈现文本。 它可以大声朗读，句子结构可以按语法进行分解，甚至单词含义也可以以图形方式显示。 这根本不符合旧的“使其易于访问”的心态 - 这是一个可以帮助每个人的可用性功能。
机器学习/人工智能正在实现全新的交互和工作方式，我们很高兴能够成为这一前沿旅程的下一阶段的一部分。 创新是由思维的变化驱动的——人类已经存在了几千年，机器已经存在了几百年，网站已经存在了几十年，而智能手机更不用说，技术必须适应人，而不是相反。
PS本文经过翻译，与原文略有偏差。 作为本文的合著者，我同意休的这些离题观点。
只有注册用户才能参与调查。 拜托
您是否关注应用程序的可访问性？
-
是
-
没有
-
这是我第一次听说应用程序可访问性。
17 位用户投票。 5 名用户弃权。
来源： habr.com