VoiceOver 大写的小词被读作缩写
VoiceOver capitalized small words are read as abbreviations
我有以下header
<h1>ADD MONEY</h1>
它正在被 VoiceOver 朗读为
a-d-d money
而如果我将文本更改为小写，它将正确读取为 "add money"。你有什么建议吗？我已经尝试使用 aria-labelledby 但没有成功！
将标记保留为小写，但使用 CSS 仅通过 text-transform 在视觉上将文本更改为大写。
然后添加 "add money" 的 aria-label。
h1 {
text-transform: uppercase;
}
<h1 aria-label="add money">add money</h1>
我建议开发人员避免在这种情况下尝试控制屏幕reader。一些原因：
- 屏幕 reader 用户（通常）很习惯这样的怪癖，并且会理解像 "add" 这样拼写的常用词。对于开发人员（和 QA 测试人员）来说似乎是一个大问题，对于整天使用屏幕 reader 的人来说实际上可能只是一个小问题。较长或不常见的单词可能更容易出现大写问题，但没有门槛。
- 它在不同的屏幕 reader 之间有所不同，并且可能归结为正在使用的语音（或文本到语音引擎）。大写的单词可能会在一个屏幕上拼写 reader，并由另一个屏幕宣布为单词。对于大多数开发人员来说，担心的太多了。
- 一些屏幕 reader 使用不同的大写方法，例如宣布 "cap" 或改变间距。
- 一些屏幕 readers 提供了这些的用户设置。在我看来，这是开发人员避免微管理屏幕 reader 体验的主要原因 - 我们可能会不经意地妨碍用户偏好。
- 随着语音引擎和辅助技术的发展，所有这一切都可能在未来发生变化。试图控制今天的公告可能会在几年后干扰辅助技术功能。 WCAG guideline 4.1 状态："Maximize compatibility with current and future user agents, including assistive technologies"（强调我的）。我认为这意味着在短期内不值得尝试对这样的小问题进行微观管理。
这里的一些答案建议使用 CSS text-transform: uppercase。这是一个很好的方法，但它在不同屏幕 reader 之间也存在不一致。在理想情况下，原始文本和文本转换都可以传递给辅助技术，为语音引擎提供更好的信息，同时尊重用户偏好。我们还没有做到这一点，但浏览器实现者正在讨论它 - 请参阅 Chromium 错误跟踪器中的讨论以获取更多详细信息：Honouring text-transform styles in the a11y tree?
另一个建议的技术是使用小写 aria-label 来复制可见文本，但强制浏览器将小写版本传递给辅助技术。例如 <button aria-label="add money">ADD MONEY</button>。这在许多情况下可能效果很好，但这是开发人员如何妨碍用户偏好的一个示例。例如，想要他们的屏幕 reader 改变首都的说话音调的用户将错过这里。屏幕 reader 的主要工作是 传达屏幕上的内容 ，包括大写字母。在我看来，小写 aria-label 技术与此不一致。
有关全部大写的讨论（在 Drupal CMS 问题中）有一些来自 screen reader 用户的有趣贡献：
Readability problem with all-caps text in core themes.
我有以下header
<h1>ADD MONEY</h1>
它正在被 VoiceOver 朗读为
a-d-d money
而如果我将文本更改为小写，它将正确读取为 "add money"。你有什么建议吗？我已经尝试使用 aria-labelledby 但没有成功！
将标记保留为小写，但使用 CSS 仅通过 text-transform 在视觉上将文本更改为大写。
然后添加 "add money" 的 aria-label。
h1 {
text-transform: uppercase;
}
<h1 aria-label="add money">add money</h1>
我建议开发人员避免在这种情况下尝试控制屏幕reader。一些原因：
- 屏幕 reader 用户（通常）很习惯这样的怪癖，并且会理解像 "add" 这样拼写的常用词。对于开发人员（和 QA 测试人员）来说似乎是一个大问题，对于整天使用屏幕 reader 的人来说实际上可能只是一个小问题。较长或不常见的单词可能更容易出现大写问题，但没有门槛。
- 它在不同的屏幕 reader 之间有所不同，并且可能归结为正在使用的语音（或文本到语音引擎）。大写的单词可能会在一个屏幕上拼写 reader，并由另一个屏幕宣布为单词。对于大多数开发人员来说，担心的太多了。
- 一些屏幕 reader 使用不同的大写方法，例如宣布 "cap" 或改变间距。
- 一些屏幕 readers 提供了这些的用户设置。在我看来，这是开发人员避免微管理屏幕 reader 体验的主要原因 - 我们可能会不经意地妨碍用户偏好。
- 随着语音引擎和辅助技术的发展，所有这一切都可能在未来发生变化。试图控制今天的公告可能会在几年后干扰辅助技术功能。 WCAG guideline 4.1 状态："Maximize compatibility with current and future user agents, including assistive technologies"（强调我的）。我认为这意味着在短期内不值得尝试对这样的小问题进行微观管理。
这里的一些答案建议使用 CSS text-transform: uppercase。这是一个很好的方法，但它在不同屏幕 reader 之间也存在不一致。在理想情况下，原始文本和文本转换都可以传递给辅助技术，为语音引擎提供更好的信息，同时尊重用户偏好。我们还没有做到这一点，但浏览器实现者正在讨论它 - 请参阅 Chromium 错误跟踪器中的讨论以获取更多详细信息：Honouring text-transform styles in the a11y tree?
另一个建议的技术是使用小写 aria-label 来复制可见文本，但强制浏览器将小写版本传递给辅助技术。例如 <button aria-label="add money">ADD MONEY</button>。这在许多情况下可能效果很好，但这是开发人员如何妨碍用户偏好的一个示例。例如，想要他们的屏幕 reader 改变首都的说话音调的用户将错过这里。屏幕 reader 的主要工作是 传达屏幕上的内容 ，包括大写字母。在我看来，小写 aria-label 技术与此不一致。
有关全部大写的讨论（在 Drupal CMS 问题中）有一些来自 screen reader 用户的有趣贡献： Readability problem with all-caps text in core themes.