aria-label、aria-labelledby 和 aria-describedby:屏幕阅读器中非常不可预见的行为

aria-label, aria-labelledby and aria-describedby: very unforeseeable behaviour in screenreaders

我刚刚注意到虽然据说 aria-labelaria-labelledbyaria-describedby 属性对每个元素都起作用(请参阅 https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-describedby),但它们似乎只起作用对于像 a 这样的一些元素,而不是例如divp 在 NVDA 和 JAWS 中。

我创建了一个小代码笔来演示这个问题(使用浏览和焦点模式浏览它):

https://codepen.io/jmuheim/pen/avWbPe

例如,在 NVDA 中,在 a 元素上,aria-labelaria-labelledby 似乎在浏览和焦点模式下都有效。但是aria-describedby只在焦点模式下公布,在浏览模式下不公布。

对于 input 元素,none 的属性似乎在浏览模式下有效,但在焦点模式下都有效。

对于 "bare" 文本元素,如 pdiv,属性的 none 似乎有效。

在 JAWS 中,它的行为非常相似,但至少对于 p 元素,当有 aria-describedby 时,它宣布可以通过按 "JAWS + alt + r" 来阅读描述.

我真的没有看到一个明确的模式,所以我想知道屏幕阅读器中关于如何使用这些属性的一般规则是什么?或者更好:为什么它们不像规范建议的那样简单地适用于每个元素?

A​​RIA 没有定义辅助技术如何公开 UI。它确实定义了 browsers are required 如何通过可访问性 API 公开角色、状态和属性。一般HTML也是一样,HTML规范没有define/requireUI,那是浏览器自己决定的。 在 aria-label 的情况下(例如),ARIA 中要求将 aria-label 映射到 accessibility APIs 中的可访问名称 属性,这不是屏幕阅读器宣布它的要求,或不在任何给定元素上(即作为听觉的一部分公开 UI)。 一般遵守的规则是屏幕阅读器将宣布 accessible names and accessible descriptions on interactive elements. They will announce accessible names on most grouping elements and sectioning elements. They will announce neither on most text level elements.

注意:以上内容也适用于任何其默认语义被 ARIA 角色覆盖的元素。例如 ARIA widget roles 将同时公布 acc 名称和描述,就像本机 HTML 交互元素一样。