accessibility - aria-label、aria-labelledby 和 aria-describedby : very unforeseeable behaviour in screenreaders

Question

我只是注意到，虽然 aria-label , aria-labelledby和 aria-describedby据说属性适用于每个元素(参见 https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-describedby )，但它们似乎只适用于少数元素，如 a ，而不是例如div或 p在 NVDA 和 JAWS 中。

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

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

例如，在 NVDA 中，在 a 上元素，aria-label和 aria-labelledby似乎在浏览和聚焦模式下都可以工作。但是aria-describedby仅在焦点模式下公布，不在浏览模式下公布。

对于 input元素，似乎没有一个属性在浏览模式下工作，但都在焦点模式下工作。

对于“裸”文本元素，如 p或 div ，这些属性似乎都不起作用。

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

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

Answer 1

ARIA 没有定义辅助技术如何暴露 UI。它确实定义了 browsers are required通过可访问性 API 公开角色、状态和属性。通常与 HTML 相同，HTML 规范没有定义/要求 UI，这由浏览器决定。
对于 aria-label(例如)，ARIA 要求将 aria-label 映射到 accessibility APIs 中的可访问名称属性。 ，这不是要求屏幕阅读器在任何给定元素上宣布或不宣布它(即作为听觉 UI 的一部分公开)。
一般观察规则是屏幕阅读器将宣布 accessible names and accessible descriptions在 interactive elements .他们将在大多数 grouping elements 上宣布可访问的名称和 sectioning elements .他们将宣布都不是 在大多数 text level elements .

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