每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。
Web 可访问性至关重要，以便残障用户获得与 Web 交互的无缝体验。让我们检查一些可能阻止公司和个人投资于适当的网络可访问性工作的神话。

今天存在的许多网站都无法访问。这会导致残障人士，尤其是那些使用辅助技术的人，无法有效地与网络互动。WebAIM 对 100 万个主页进行了一项研究，检测到 50,829,406 个不同的可访问性错误——平均每页 50.8 个错误。 根据 UsableNet的数据，2022 年网络可访问性诉讼正在增加，每周有近 100 起诉讼。但是，对诉讼的恐惧不应成为您投资网络可访问性的原因。这个星球上有超过十亿残疾人，他们应该拥有访问网络的人权。以下是一些可以阻止公司和个人投资于适当的网络可访问性工作的神话：

我的用户不需要它

假设您的用户没有被禁用是错误的，因此您不需要使您的网站可访问。但是，重要的是要记住，大多数残疾是不可见的或不明显的。据美国残疾人组织Lime Connect称，校园内 90% 的残疾人是隐形的。绝大多数残疾人甚至没有透露他们有残疾。除此之外，残疾也是暂时的和情境性的。例如，手部暂时受伤并且不得不使用语音转文字。设计具有可访问性的软件铭记对每个人都有好处，而不仅仅是残疾人。想想字幕。最初，字幕是为了帮助聋哑/重听人群而发明的，但我们中的许多人几乎总是在观看 Netflix 时使用字幕！

自动化测试将修复我的网站

许多自动化测试工具，例如Deque 的 Ax、Google 的 Lighthouse或Microsoft 的 Accessibility Insights都非常擅长捕捉网页上的许多可访问性错误。根据 Deque 的说法，自动化工具现在可以捕获您网站上 57% 的可访问性问题，而行业认为这一比例为 20-30%。例如，自动化测试将能够捕获您的表单缺少的标签，或者您的图像缺少替代描述。但是，它能够确定这些标签和描述的准确性吗？不会。除此之外，自动化测试也不会捕获大多数键盘导航、焦点陷阱、表单提交等可访问性问题。因此，执行手动测试非常重要，最好是对残疾人进行测试。许多公司都有可访问性程序，您的产品通过手动测试可访问性。如果您是一家没有可访问性知识库的小公司，请联系诸如Knowbility、Equal Entry、Fable等咨询公司等谁可以为您提供有关如何开始使用的建议并就您的产品的可访问性提供反馈。除了手动测试之外，在设计和开发过程中左移也很重要。左移意味着可访问性测试必须尽可能早地开始，而不应该留在最后。这可以通过在 CI 开发过程中嵌入自动化测试来完成，同时迭代您的线框图和用户研究以实现可访问性。

我可以只使用叠加层

如今，一些公司提供了各种可访问性解决方案，声称可以通过一行代码修复您网站上的可访问性。这些被称为可访问性小部件或覆盖。这些叠加层存在各种问题。首先，它们提出了一种有缺陷的可访问性方法。可访问性不是绷带或附加组件。由人工智能驱动的一行代码不会使您的网站易于访问。无障碍工作需要有意识的努力和对残疾人的同情。可访问性不仅仅是合规性。
其次，它们不会使您免于可访问性诉讼，因为它们并没有真正起作用。据 UsableNet 称， 使用无障碍小部件的企业收到了 300 多起诉讼。此外，许多残疾人对他们与此类覆盖的斗争持开放态度。叠加情况说明书有很多这样的证明，说明为什么叠加是一个坏主意。一篇这样的评论说：“有一个非常实用的工具可以让网站易于访问。它被称为程序员。使网站可访问的重要需求是用户的需求。如果你不能满足这些，那么你就无法满足做生意的基本成本。”
此外，覆盖也可能导致某些安全问题。根据叠加情况说明书, “已发现一些覆盖在使用相同覆盖的站点之间保留用户的设置。这是通过在用户的计算机上设置 cookie 来完成的。当用户在一侧启用覆盖功能的设置时，覆盖将自动在其他站点上打开该功能。虽然覆盖公司可能认为最终用户做得很好，但最大的隐私问题是用户从未选择被跟踪，也没有选择退出的能力。由于缺乏选择退出（除了明确关闭该设置），这会给覆盖客户带来通用数据保护条例 (GDPR) 和加州消费者隐私法 (CCPA) 风险。”

现代 Web 框架不是为可访问性而构建的

您需要将网站构建为纯 HTML 和 JavaScript 才能嵌入可访问性，这不是真的。许多现代 Web 开发框架（例如 React JS）都支持可访问性。例如，React 文档有一整页专门用于使用标准 HTML 技术的可访问性。所有 Web 框架都建立在标准 HTML 之上，因此总会有机会改进可访问性。您还可以使用可访问性代码 linter，它们是静态代码分析工具，可以在编写代码时捕获可访问性错误，这将帮助您“左移”，如 #2 中所述。以React 的 Accessibility Code Linter 为例，它可以通过 NPM 安装。根据您的设置方式，linter 将在您的 Web 浏览器的控制台、您的编辑器或您的持续集成环境中报告 [可访问性] 问题。

我需要成为屏幕阅读器专家

屏幕阅读器是盲人/低视力人士用来浏览网络的文本到语音转换工具。毫不夸张地说，由于无法访问，盲人最难使用网络 - 因此，许多网络可访问性的努力都是针对屏幕阅读器可访问性的。但是，您无需成为屏幕阅读器专家即可开始设计和开发时考虑到可访问性。知道如何使用屏幕阅读器当然是一种奖励，但创建可访问的网站与测试它们不同。

总结

通过在代码中实施良好的可访问性实践，您可以间接地使屏幕阅读器可以访问它们。如果您对如何使 UI 组件可访问感到困惑 - 请查看ARIA 创作实践指南，其中提供了许多设计模式和可访问用户界面应如何表现的示例。此外，请查看Google Chrome 的辅助功能树（可以在开发工具中找到），它可以帮助您查看 Web 应用程序的辅助功能结构和属性。您也可以使用Paul Adams 书签它将突出显示页面上 HTML 元素的角色、状态和属性。这些工具可以帮助您查找和修复可访问性错误。屏幕阅读器使用这些角色、状态和属性将信息传达给屏幕阅读器用户，因此确保设置这些适当的属性非常重要。
这并不是说屏幕阅读器测试不重要。它肯定是。但是，使用屏幕阅读器有一个学习曲线，这不应该阻止您设计和开发可访问性。屏幕阅读器测试最好留给专业测试人员，他们是这样做的专家。