JAWS 脚本是否会覆盖屏幕 reader 读取 DOM 的能力？

Will a JAWS script override a screen reader's ability to read the DOM?

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

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

具体来说，我想弄清楚： 问题 1) 如果存在 JAWS 脚本，它是否会被 browser/screen reader 独占使用并忽略我在底层 HTML 结构中所做的任何改进？

问题 2) 一些适当放置的 ARIA 属性是否可以为页面提供足够的结构，以便默认屏幕 reader 属性将以可接受的方式工作（没有 JAWS 脚本）。

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

非常感谢任何输入。

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

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

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

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

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

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

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

让您的 application/site 易于访问的绝对最佳方法是 use semantic HTML。 HTML 是由 asp 或 jsp 或其他什么生成的并不重要。

如果您有 table，请使用

。
如果您有标题，请使用

.
如果您有列表，请使用
    .
    使用
    、
    、