无障碍性和网站性能并非功能，而是基础

本周我一直在思考网站性能和无障碍性。这一切都始于 Ethan Marcotte 做了许多关于 AMP 常用的无障碍性问题 的精彩笔记

在上面的录音中，我尝试在 AMP 故事中导航。在导航过程中，VoiceOver 描述了一个无法理解的页面：后退或前进的箭头仅被宣布为“按钮”；大多数图像缺少文本等效项，这就是屏幕阅读器拼出其文件名中每个字符的原因；当故事的内容在屏幕上可见时，几乎无法访问。我想说这个 AMP 故事是一个特例，但 AMP 故事网站上列出的九个演示中的每一个 在 VoiceOver 中听起来都同样难以理解。

Ethan 继续争论说，这些问题在 AMP 中非常普遍，以至于无障碍性根本不应成为优先事项

从一开始，Google 就坚持认为 AMP 是解决网络性能问题的最佳方案。并且 Google 利用其市场支配地位迫使发布者采用该框架，甚至暗示 AMP 是您在网络上发布页面的唯一格式。但我们已经到了 AMP 可能通过增强网络的无障碍性问题来“解决”网络的性能问题的地步，这使得更多的人无法访问他们应得的内容。

我最近一直在思考这个问题——关于无障碍性工作如何常常被视为可以在项目后期附加的功能——而不是将无障碍性工作视为网络工作中的核心原则或标准。

而且我一次又一次地看到这种情绪在框架中、在 Twitter 上、在设计过程中、在开发过程中表达，以至于争论无障碍性的重要性可能会让人感到筋疲力尽。因为在某些时候，我们争论的不是无障碍性的重要性，而是前端开发本身作为一系列值得拥有的技能的重要性。 无法替代的技能。

类似地，Craig Mod 的这篇关于 为什么软件应该闪电般快速 的文章让我产生了同样的想法

我喜欢快速的软件。也就是说，软件在功能和界面上都非常快速。在想要激活或操作某些内容与该内容发生之间，软件的延迟最小或没有延迟。轻盈。

在文章的后面，Mod 将快速软件描述为良好软件的定义，并认为计算机上的每个操作——无论是网站还是应用程序——都应该感觉像是在没有任何延迟的情况下移动。我完全同意；每个加载屏幕和等待时间在某种程度上都是失败的标志。

Alex Russell 不久前也提出了类似的观点，当时他查看了 手机的性能 并检查了每个人如何在 截然不同的方式 中体验网络

这里的要点是，如果您试图为除世界上最富有的用户以外的任何人创建良好的网络体验，那么您实际上负担不起桌面或 iPhone 级别的 JS，这可能意味着重新评估您的工具链。

在这些方面，我有点像个混蛋。我认为一个网站只有在速度快的时候才能算得上好。那种让你屏息凝神的速度。像人类的思想一样快，甚至更快。因此，我在这里的观点是，网站性能不是我们应该追求的目标，它应该是标准。现状。衡量我们工作成果的基准。在速度足够快之前，它不应该被发布。

好消息是，现在发布一个具有无与伦比的速度和无障碍性的基本要求的网站比以往任何时候都更容易！我们有 Page Speed Insights 和 Web Page Test，更不用说能够让 Lighthouse 在我们工作的过程中自动在 GitHub 中的每次提交中执行审核。Ire Aderinokun 不久前向我们展示了如何通过设置 性能预算 并学习如何坚持它来做到这一点。

使我们的网站快速且易于访问的工具已经存在，但我们没有使用它们。这就是让我生气的原因。

---

趁着我还在抱怨——并且在我从我特别高的道德制高点下来之前——我认为有必要注意 Deb Chachra 的论点，即“任何足够先进的疏忽都与恶意难以区分”。考虑到这一点，如果一个网站速度很慢，那不仅仅是糟糕的软件设计和开发。性能和无障碍性不是可以在 Jira 看板的底部停留以供日后方便时考虑的功能。

相反，我们必须开始将无法访问和缓慢的网站视为它们本来面目：一种残酷行为。如果我们想要构建一个真正意义上的万维网，一个适合所有人和每个人的地方，一个尽可能多的人都能访问且快速的网络，以及一个将超越我们所有人存在的网络，那么首先我们必须使我们的网站成为完全不同的东西；我们必须让它们变得友好。