我正在为表单控件创建可访问的帮助文本。我计划使用aria-describedby将可访问的描述附加到字段。 here
尽管在使用ChromeVox扩展程序和Windows 10屏幕阅读器进行测试时，我发现aria-describedby尚未发布，but it is rather well supported across browsers and screenreaders，所以我打算使用这种方法。
也this建议在某些情况下aria-describedby将被忽略或无法按预期工作，但是这些情况是非常具体的，我一般都同意。
内容所描述的aria可能不会始终向用户发布， 取决于他们的屏幕阅读器和导航方法。属性 得到了很好的支持，但这并不意味着没有什么要 注意：咏叹调所描述的内容可能不会被所有人宣布 屏幕阅读器（如果使用导航到按钮，链接或表单控件） 虚拟光标。 JAWS可能不会宣布元素的 使用热键导航到某些元素时的描述。什么时候 通过访问的链接进行导航，则不会宣布其描述。 但是，JAWS应该在通过表单导航时宣布描述 控件。 JAWS 17 + IE不会在内容发布时通过内容描述咏叹调 跳至链接（较新版本的JAWS已修复此问题）。 IE11不会 宣布表单控件的可访问名称或描述，如果
title属性与aria-by描述一起使用，并且 用户正在通过虚拟光标或窗体控制热键（F）进行导航。都 如果使用Tab键将被宣布。 （IE11有更大的问题 带有aria-过去所描述的内容。）TalkBack + Android Chrome不会 在以下情况时宣布模式对话框内容所描述的任何咏叹调 在该对话框中自动聚焦一个元素。如果用户有 说明或提示文字已关闭，因此不会关联任何相关内容 宣布。因此，至关重要的是 理解UI所必需的方法可以通过其他方式获得 不仅仅是咏叹调所描述。
我想了解是否有时aria-describedby不会自动宣布吗？以前的链接措词似乎表明，仅应要求公开：
通过使用aria- describeby来引用字段格式，这 信息可应要求提供给用户。那就是 不会自动显示或朗读。如果 之前或当有很多格式被告知用户时 例如，输入格式相同的字段。
我不明白“应要求”是什么意思。我认为默认行为是在宣布标签和输入类型后宣布文本所描述的咏叹调。
答案 0 :(得分：1)
aria-describedby（如aria-label和aria-labeledby）的行为受到它们出现的元素的作用的深刻影响。
您可能已经知道，屏幕阅读器通常使用two 'modes'，这主要取决于内容的作用（或默认语义）。
如果非交互式元素出现在交互式（“表单模式”）内容中，我肯定会遇到问题。
将aria-describedby与模式内容一起使用时，我取得了很好的效果。 （将属性放在模式上，并在模式打开时指向要在其中声明的文本元素。）但是我想这是因为屏幕阅读器应该在一个明显的时刻发出这些通知：模式打开。
如果表单（或其他“表单模式”容器）始终显示在页面上，则通常可以使用浏览模式键组合（例如“下一个标题”（“ H”）来读取非交互式内容在NVDA和JAWS上）或“下一段”（“ P”）。检查这些“请求”是否足以解决问题。
您还可以尝试使用标准HTML元素fieldset和legend，其目的是为交互式元素组提供文本描述。
还可以考虑将“表单”（或工具栏或其他）视为单个制表符，并使用箭头键浏览其中的组件。这样，当您将焦点放在容器上时，应该得到aria-describedby（或者实际上是aria-labeledby / aria-label）的公告
如果这对您不起作用，那么您可以尝试以下几种方法：
tabindex="-1"放在所需文字周围的元素上
宣布，然后在适当的位置对该元素调用focus()
片刻。aria-live区域的textContent中
在适当的时候使用javaScript。如果没有“适当的时机”，这些技巧都不是很漂亮，并且可能不适合您。 （浏览模式没有onfocus的等效项）。但是，只要稍加注意，就可以使它们起作用。