提问者:小点点

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


我正在为窗体控件创建可访问的帮助文本。我计划使用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文本。


共1个答案

匿名用户

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

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

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

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

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

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

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

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

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

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