可访问性：在什么情况下ARI-DescribedBy不会被公布？

Question

我正在为窗体控件创建可访问的帮助文本。我计划使用aria-descripedby将可访问的描述附加到字段。这里讨论这种方法

虽然在使用ChromeVox扩展和Windows10屏幕阅读器的测试中，我发现aria-describedby没有公布，但它在浏览器和屏幕阅读器中得到了很好的支持，所以我计划使用这种方法。

此外，这表明在某些情况下aria-describedby会被忽略，或者不会像预期的那样工作，但这些情况非常具体，我通常可以接受。

aria-descripedby内容可能并不总是向用户公布，这取决于他们的屏幕阅读器和导航方法。该属性得到了很好的支持，但这并不意味着没有一些事情需要注意：如果使用虚拟光标导航到按钮、链接或窗体控件，则所有屏幕阅读器可能不会宣布aria-descripedby内容。当使用热键导航到某些元素时，jaw可能不会宣布元素的描述。当通过访问的链接导航时，描述不会被宣布。但是，当通过表单控件导航时，JAW应该宣布描述。Jaws17+IE在跳转到链接时不会公布ARIA-DescripdBy内容（更新版本的JAWS已经修复了这个问题）。如果title属性与aria-descripedby一起使用，并且用户通过虚拟光标或表单控件热键(F)导航，则IE11不会宣布表单控件的可访问名称或描述。如果使用Tab键，这两个都将被宣布。（IE11在过去对aria-describedby有更大的问题。）TalkBack+Android Chrome不会在自动对焦模式对话框中的元素时公布任何ARIA描述的内容。如果用户关闭了描述或提示文本，则不会公布任何相关内容。正因为如此，理解UI所必需的任何内容都必须通过ARI-DescribedBy以外的方式获得。

我想知道是否有aria-describedby不会自动宣布的时候？前面的链接措辞似乎暗示只有在请求时才会公布：

通过使用aria-descripedby引用字段的格式，用户可以根据请求获得这些信息。即不自动显示或大声朗读。例如，如果用户之前已经知道了格式，或者有很多相同格式的输入字段时，这是有意义的。

我不明白“应要求”是什么意思。我相信默认的行为是在宣布标签和输入类型之后宣布aria-descripedby文本。

Answer 1

aria-descripedby（与aria-label和aria-labeledby)的行为受到它们所在元素的角色的深刻影响。

您可能知道，屏幕阅读器通常有两种“模式”，这主要由内容的角色（或默认语义）决定。

如果非交互式元素出现在交互式（“表单模式”）内容中，我肯定会遇到一些问题。

我使用带有模态内容的aria-descripedby获得了很好的结果。（将属性放在模态上，并指向您希望在模态打开时宣布的文本元素。）但我想这是因为有一个显而易见的时刻，屏幕阅读器应该做出这些宣布：模态打开的时刻。

如果表单（或其他“表单模式”容器）总是出现在页面上，通常可以使用浏览模式组合键（如“下一个标题”（NVDA和JAWS上的“H”）或“下一个段落”（“P”））读取非交互式内容。看看这些‘请求’是否足够作为解决方案。

您还可以使用标准HTML元素fieldset和legend，它们的目的是为交互式元素组提供文本描述。

还可以考虑将“表单”（或工具栏或其他）视为单个制表位，并使用箭头键来导航其中的组件。这样，当您将焦点放在容器上时，您应该会得到关于aria-descripedby（或者确实是aria-labeledby/aria-labelable)的公告

如果这对您不起作用，您可以尝试以下几种方法作为最后的手段：

• 将tabindex=“-1”放在要宣布的文本周围的元素上，然后在适当的时候对该元素调用focus()。
• 在适当的时候使用javaScript将文本复制到aria-live区域的textContent中。

如果没有“合适的时机”，这两种方法都不是很漂亮，也可能不适合你。（对于浏览模式，没有onfocus等价物）。但只要稍加小心，它们就能发挥作用。