JAWS 脚本会覆盖屏幕阅读器读取 DOM 的能力吗？答案

【问题标题】：Will a JAWS script override a screen reader's ability to read the DOM?JAWS 脚本会覆盖屏幕阅读器读取 DOM 的能力吗？
【发布时间】：2019-08-12 10:03:55
【问题描述】：

我的任务是评估一些遗留网页（经典 asp）的可访问性。您可以假设 HTML 的格式不完美，并且它加载了内联 javascript，并且我们使用 javascript 库来创建动态特性。里面是马戏团。

虽然我认识到显而易见的答案是重写页面，但这不是我们给定时间表中的选项。所以我试图找到使页面与屏幕阅读器一起工作的最佳方法。以下是我认为我知道的。

我们可以使用 JAWS 脚本来指示浏览器如何读取页面。
我们可以使用 ARIA 属性为页面提供更好的组织和结构。

具体来说，我想弄清楚：问题 1) 如果存在 JAWS 脚本，它是否会被浏览器/屏幕阅读器专门使用而忽略我在底层 HTML 结构中所做的任何改进？

问题 2) 一些适当的 ARIA 属性能否为页面提供足够的结构，以便默认屏幕阅读器属性以可接受的方式工作（无需 JAWS 脚本）。

问题 3) 我怀疑很难回答是我需要两者都做，我试图避免这种情况，因为我们几乎没有能力只做一个。但我们当然不想失去客户。 :-(

非常感谢您的任何意见。

【问题讨论】：

我不确定其他辅助技术如何/是否使用 JAWS 脚本。你只针对 JAWS 吗？ ARIA 应该在其他媒体上获得更广泛的支持。如果您需要更具体的帮助，请分享您的页面标记。
您知道，屏幕阅读器支持只是辅助功能的一部分吗？不要忘记键盘导航、在不破坏布局的情况下调整文本大小、足够的对比度、对其他输入模式的容忍度等。
客户坚持我们使用 JAWS，因为那是他们的屏幕阅读器。我主要是想弄清楚我应该走哪条路。 JAWS 脚本或 ARIA 改造。我更喜欢 ARIA 改头换面，但如果我上传了一个示例页面，你会目瞪口呆，我什至不确定 ARIA 是否能让页面足够清晰。
这个项目的快速更新：我们主要选择了 aria-attributes 的一些战略用途。目标不是打造完美的 ADA 体验。目的是为屏幕阅读器提供可以通过的体验，目标是在未来进行更好的修复。为此，充分利用以下 aria 属性对我们有用： aria-label 强制屏幕阅读器读取该标签中的任何内容 aria-required aria-invalid 标记错误和 aria 角色这些让我们到一个好地方。这是一项繁重的工作，但它成功了。

标签： accessibility jaws-screen-reader

【解决方案1】：

不要只向 JAWS 解释如何访问您的页面，而是使用 JavaScript 向任何网络辅助技术 (AT) 解释它。我期待同样的努力，同时它会为更多的用户带来收益。

在 JAWS 脚本中，您需要描述访问不可访问的 DOM 节点的方法。这将包括

说出您必须在页面其他地方找到的信息
在缺少的地方添加键盘导航

两者都可以在 JavaScript 中完成，可能更简单（您需要处理 DOM 元素）。

您需要避免重组 DOM 和更改类，因为生成它们的脚本最有可能使用这些。

但我希望添加属性和键盘处理程序不会对现有脚本造成损害。不过，请注意已经存在的 focus 或键盘事件处理程序。

我建议列出您怀疑与现有脚本冲突的属性和处理程序，并在脚本中搜索这些，例如 onkeypress 或 onfocus 事件处理程序。

【讨论】：

我没有考虑过这个选项。它可能足够引人注目，可以深入一点，因为它可能是最轻的解决方案（这就是我正在寻找的）。我们内部没有任何 JAWS 或 ARIA 专业知识。感谢您分享这个想法。
我选择这个作为我的答案，因为它在我的情况下最适合我。我正在寻找一种轻量级的方法来使页面正常工作。最大的障碍是我们的技能。我很确定我们可以找到掌握 JAWS 脚本并处理浏览器和版本不兼容问题的人，但是，这不会在 6 周内发生。我还发现了一个可访问性 JavaScript 库 (allyjs.io)，它可能对我的工作有所帮助。感谢您的见解。
只是想跟进javascript的智慧。在学习了 JAWS 之后，我们了解到 JAWS 脚本编写可不是开玩笑的。它带来了处理具有不同版本的不同用户的大量维护。如果你有一个 SaaS 应用程序，不同的客户会有不同的体验。然后你有浏览器问题。如果你有很多 javascript，你会遇到问题。我在创建一个清理页面元素并使通用屏幕阅读器工作得更好的 javascript 函数方面取得了很大进展。可能不完全合规，但页面可以正常工作。
感谢您的更新。你发现的 allyjs 库对你有用吗？如果是的话，我认为这将是对答案的一个很好的补充。
我实际上并没有使用 allyjs。我简单地看了看它，但很快就了解到客户主要是在寻找可以帮助屏幕阅读器的快速工具。最快的方法是在关键位置添加 aria-labels、'roles'、aira-invalid 属性。几天的模拟工作使事情达到了可以接受的状态。

【解决方案2】：

让您的应用程序/站点可访问的绝对最佳方式是use semantic HTML。该 HTML 是由 asp 还是 jsp 生成的都没有关系。

如果您有一张桌子，请使用

。
如果您有标题，请使用

。
如果您有列表，请使用

、

等

这就是您在页面上创建屏幕阅读器用户会喜欢的结构的方式。

如果你不能使用原生 HTML，那么回退到 ARIA，但把它当作盐。一点点会大大增强味道，但太多会破坏饭菜。

如果您不能使用原生

，请确保使用适当的角色和属性。

<div role="heading" aria-level="2">this is my custom h2</div>

如果您不能使用原生

，请确保使用适当的角色和属性。

<div role="banner">my header stuff goes in here</div>

我建议完全忘记 JAWS 脚本。客户是否认为他们应该关注我们并不重要。这与客户无关。这是关于那个客户的客户。最终用户。他们应该能够使用他们习惯使用和最熟悉的任何屏幕阅读器。这就是可访问性的全部目的 - 让尽可能多的人使用他们习惯使用的任何辅助技术来使用和访问网站。

遵循Web Content Accessibility Guidelines (WCAG) 将引导您获得该结果。

【讨论】：

我在理论上同意语义 HTML。由于页面的混乱，此时这并不是一个真正的选择。我们主要是在寻找一种轻量级的方法来解决这个问题，我希望能够澄清 JAWS 脚本和 ARIA 之间的关系。我们在这两个领域都没有专家。听起来好像没有简单的路径，并且修复必须以 ARIA 的形式来清理结构和 JAWS 脚本以使屏幕阅读器工作。我喜欢下面介绍的 javascript 想法，但需要研究它是如何工作的