VoiceOver 的剧透问题

错误
, ,
1

继续讨论 Spoiler blur not compatible with screen readers：

我收到了一份来自 VoiceOver 用户关于新 spoiler 代码无效的报告：

我论坛上的屏幕阅读器用户在使用更新后的 spoiler 功能时是否遇到过困难？我假设一定有更新——以前 spoiler 文本会正常朗读，没有任何隐藏的提示，这当然不理想。更新似乎通过将内容放在一个标有“显示隐藏内容”的可折叠区域后面解决了这个问题，但不知何故，当我按下展开/显示按钮时，文本没有被读取出来。供参考，我使用的是 Voiceover，苹果的原生屏幕阅读器，并且我在 iOS 和 Mac OS 上都注意到了这个问题。

3 个赞
3

有人说

我在使用 Windows 上的 NVDA 时也有同样的问题。

第三个人也表示同意。

抱歉，但目前的代码似乎无法正常工作！最好还是回滚到旧代码。

1 个赞
6

嘿 @Dannii，感谢你发现此问题。我刚刚发布了一个修复程序，现在应该可以改进行为，以便屏幕阅读器在展开折叠内容后能够朗读其内容。

4 个赞
7

我已经升级了论坛，但屏幕阅读器用户报告说对他们来说没有任何变化。

1 个赞
8

您确定插件已升级到最新版本吗？（提交 0ee68da）

在 Meta 上，我使用 VoiceOver 测试时似乎可以正常工作。我们还为此使用了 aria-live（设置为 polite），这意味着屏幕阅读器不会那么强势和干扰。相反，它会等待用户空闲时再朗读内容。

测试这个会读出来

1 个赞
9

是的，剧透插件是 0ee68da1。

1 个赞
11

Keegan，你能多说一点关于你如何测试这个吗？你的截图看起来像桌面浏览器。你使用的是 macOS VoiceOver 吗？（在哪个浏览器上？）

macOS VoiceOver 与 iOS VoiceOver 是截然不同的产品。macOS VoiceOver 中经常会出现 iOS VoiceOver 中没有的 bug，反之亦然。（由于各种原因，iOS VoiceOver 在视障用户中的普及程度远远高于 macOS VoiceOver。）

当我尝试在 iOS Safari 16.3.1 上测试你的帖子 https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich 时，我看到了这个：

以下是文字记录：

  • 视频开始时焦点在视频上。然后我向右滑动以聚焦模糊的隐藏内容文本。
  • VoiceOver 播报：“显示隐藏内容。按钮。已折叠。双击展开。”
  • 我双击。隐藏内容文本在视觉上变得清晰。
  • VoiceOver 播报：“隐藏内容。已展开。隐藏内容。”我声称这是 Discourse 中的一个 bug。它应该像 keegan 的视频中那样朗读文本内容。
  • 我向右滑动，导航到下一个 UI 控件。
  • VoiceOver 播报：“一个人喜欢这个帖子。点击查看。切换按钮。”
  • 我向左滑动，导航回清晰的隐藏内容文本。
  • VoiceOver 播报：“隐藏内容。按钮。已展开。双击折叠。”
  • 然后我再次向右和向左滑动，只是为了再次检查是否发生相同的行为，结果确实如此。

我们收到了来自 intfiction.org 论坛用户的报告，称 NVDA 中的隐藏内容模糊也坏了，这可能值得你在你的终端上进行测试。

2 个赞
12

嘿 @dfabulich，感谢分享这些细节。是的，我主要在 Chrome 上进行了测试（macOS VoiceOver 和 Windows 11 讲述人）。

我会做更多挖掘/测试，看看是否能尽快推出一个解决方案，以解决 iOS、NVDA 和其他主要设备的问题。

谢谢！

3 个赞
13

是的，这两个都不是真正流行的屏幕阅读器，不应作为您的主要测试平台。

这是 WebAIM 对屏幕阅读器用户进行的行业主要调查。

https://webaim.org/projects/screenreadersurvey9/ （他们每隔几年会重新进行一次此调查；这是 2021 年的）

现在，您需要仔细阅读此调查，因为它首先讨论桌面浏览器，并有一个“主要屏幕阅读器”图表 https://webaim.org/projects/screenreadersurvey9/#primary，但它专门指的是主要的“桌面/笔记本电脑”屏幕阅读器。

该图表表明“VoiceOver”并不流行，但它在该部分指的是 macOS VoiceOver。（如果您向下滚动到“操作系统”部分，您会看到 macOS 本身在屏幕阅读器用户中并不流行。）

Windows 的 JAWS 是领先的屏幕阅读器，其次是 Windows 的 NVDA。macOS VoiceOver 遥遥领先。Windows Narrator 的使用率为 0.5%！

请注意，JAWS 是收费的（并且其许可方案很繁琐），而 NVDA 是免费的。但是，NVDA 也比 JAWS 容易出现错误；据我所知，在 NVDA 中可以正常工作的任何内容在 JAWS 中也可以正常工作。

之后，它讨论了“使用的移动屏幕阅读器” https://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders

该图表显示，操作系统内置的屏幕阅读器占主导地位，iOS VoiceOver（71.5%）和 Android TalkBack（29.1%）。（这些加起来超过 100%，因为有些人同时使用两者。）

此调查缺少“移动时间与桌面时间”的调查，但根据我的经验，我从屏幕阅读器用户那里听到的绝大多数错误报告都来自 iOS 用户和 NVDA 用户。

因此，我建议按以下优先级顺序进行测试：

  1. iOS Safari VoiceOver。我推荐移动设备而不是桌面设备（因为，我声称没有数据支持，移动设备在视障用户中更受欢迎），以及 iOS 而不是 Android，因为 iOS 在视障用户中的受欢迎程度远远超过 Android。
  2. Windows Chrome 上的 NVDA。NVDA 的受欢迎程度不如 JAWS，但它更容易出错。在 NVDA 中可以正常工作的任何内容也将在 JAWS 中正常工作，但反之则不一定。
  3. Windows Chrome 上的 JAWS。
  4. Android Chrome 上的 TalkBack。
  5. macOS Safari 上的 VoiceOver。

但我认为您会发现，仅在 iOS Safari VoiceOver 中进行测试就能获得极高的性价比。我通常只测试 iOS Safari，然后想非常彻底地测试 Windows Chrome 上的 NVDA，之后我通常就会停止。

自从我看到用户报告在 Windows JAWS 中出现但在 Windows NVDA 中未出现的错误以来，至少已经有五年了。我想我从未收到过关于 Android TalkBack 错误的报告。

4 个赞
14

这个问题有进展了吗？

15

aria-live 不应被切换。您应该在开始时将其设置为 polite，然后保持不变。在现有实现中，由于在 aria-live 开启时从未发生过更改，因此它永远无法识别出更改已发生。

1 个赞
16

对我来说（NVDA/Windows）的问题似乎是，你们有一个带有 aria-label 的外部 div。我相信在大多数屏幕阅读器中，这并不是内容的注解，而是无法访问内容的替代。至少，aria-label 是我唯一能读到的东西。

这是这个主题中剧透的录音：读取视频底部的进度条，然后是空白（不知道那是什么），然后是可见的剧透（“按钮已展开，隐藏内容”），然后是“2 条回复”下拉菜单。

请注意，如果我使用 NVDA 的调试功能并将鼠标悬停在展开的文本上进行阅读，它会读取。但我还没有找到任何方法可以在不使用鼠标的情况下让它读取文本。所以这似乎不是测试它是否真正可访问的有效方法……

2 个赞
17

我提交了一个 PR，包含了一些可访问性改进：

3 个赞
19

感谢 @Dannii 的 PR :slight_smile:

我已经审阅了它并添加了一些评论，只是非常小的改动，但除此之外它看起来很棒！

1 个赞
21

感谢 @Dannii，您的 PR 已合并 :slight_smile: 此问题现已解决

2 个赞