咏叹调标签，咏叹调标签和咏叹调描述：屏幕阅读器中非常不可预料的行为 [英] aria-label, aria-labelledby and aria-describedby: very unforeseeable behaviour in screenreaders

问题描述

我刚刚注意到，尽管 aria标签， aria标签由和 aria -describeby 属性据说适用于每个元素（请参见 https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria- describeby ），它们似乎仅适用于一个，而不是例如 div 或 p 在NVDA和JAWS中。

I just noticed that although the aria-label, aria-labelledby and aria-describedby attributes are said to work on every element (see https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-describedby), they only seem to work for a few elements like a, and not for e.g. div or p in NVDA and JAWS.

I已经创建了一个小的Codepen来演示该问题（使用浏览和焦点模式浏览）：

I have created a small codepen to demonstrate the issue (browse it using browse and focus mode):

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

例如，在NVDA中， a 元素， aria标签和 aria-labelled 似乎在浏览和焦点模式下都可以工作。但是由描述的aria仅在焦点模式下宣布，而不是在浏览模式下宣布。

For example, in NVDA, on the a element, the aria-label and aria-labelledby seem to work in both browse and focus mode. But aria-describedby is only announced in focus mode, not in browse mode.

对于 input 元素，似乎所有属性都无法在浏览模式下工作，但所有属性都可以在焦点模式下工作。

For the input element, none of the attributes seem to work in browse mode, but all work in focus mode.

用于裸露文本诸如 p 或 div 之类的元素，这些属性似乎都不起作用。

For "bare" text elements like p or div, none of the attributes seem to work.

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

In JAWS, it's quite similar behaviour, but at least for the p element, when there is an aria-describedby, it announces that a description can be read by pressing "JAWS + alt + r".

我真的看不到明确的模式，所以我想知道屏幕阅读器中有关如何使用这些属性的一般规则是什么？或者更好：为什么不按照规范的建议简单地为每个元素工作？

I don't really see a clear pattern for this, so I wonder what are the general rules in screenreaders on how to use these attributes? Or better: why don't they simply work for every element, as the spec proposes?

推荐答案

ARIA并未定义辅助性技术将公开用户界面。它确实定义了如何浏览器通过可访问性公开角色，状态和属性。蜜蜂。一般而言，HTML都是相同的，HTML规范没有定义/要求用户界面，这取决于浏览器来决定。
例如，对于aria-label，ARIA要求将aria-label映射到可访问性API ，这不是屏幕阅读器在任何给定元素上是否宣布它的要求（例如，作为听觉UI的一部分公开） 。
一般观察到的规则是屏幕阅读器会宣布可访问的名称和可访问的描述在互动元素上。他们将在大多数分组元素和< a href = http://www.w3.org/TR/html5/dom.html#sectioning-content rel = noreferrer>部分元素。他们不会在大多数文本级别元素。

ARIA does not define how assistive tech are to expose UI. It does define how browsers are required to expose roles, states and properties via accessibility APIs. It's the same with HTML in general, the HTML spec does not define/require UI, that is left up to the browsers to decide. In the case of aria-label (for example) it is a requirement in ARIA that aria-label is mapped to the accessible name property in accessibility APIs, it is not a requirment that screen readers announce it, or not, on any given element (i.e. expose as part of the aural UI). General observed rule is that screen readers will announce 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小部件角色将同时宣布acc名称和描述，像原生HTML互动元素。

Note: the above also applies to any element that has it's default semantics overidden with ARIA roles. For example ARIA widget roles will have both acc name and description announced, like native HTML interactive elements.

这篇关于咏叹调标签，咏叹调标签和咏叹调描述：屏幕阅读器中非常不可预料的行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！