对我的问题的分析。
盲人使用屏幕阅读器与应用程序进行交互。这些屏幕阅读器以优选的语速和其他设置说出内容，消息等。从开发人员的角度来看，还具有一些便利的功能：将文本传递到屏幕阅读器时，它可以是断言的（因此中断屏幕阅读器）或礼貌的（屏幕阅读器会先完成当前文本的阅读，然后再移至下一个）文字）。
但是，某些盲人（或聋哑人）另外或仅使用盲文显示器。盲文显示器（理想情况下）显示屏幕阅读器正在阅读的文本或它的合适版本。实际上，如果许多屏幕阅读器未将盲文显示用户配置为不通过盲文显示来阅读屏幕阅读器日志而不是查看当前应用程序，则会剥夺他们的某些信息。
我正在创建带有盲文支持的音频游戏。这本身并不寻常-大多数音频游戏就是这样：音频。
我的第一个问题是如何让屏幕阅读器朗读消息并将其同时传递给盲文显示器。解决方案是 Tolk screen reader abstraction library
它可以像宣传的那样工作，但是Tolk无法解决一个问题：盲文消息的发送速度太快了。由于盲文消息已在许多屏幕阅读器（如果不是全部）中实现，因此如果两个消息一个接一个地发送，则它们几乎同时到达，从而使用户没有时间阅读第二个消息之前的第一个消息（如果他们根本没有注意到第一条消息。
在Tolk中，有一个函数Tolk_IsSpeaking()，如果屏幕阅读器正在讲话，则返回true，否则返回false，或者如果屏幕阅读器未实现该功能，则返回false。
这是主要问题：大多数屏幕阅读器都有一个缓冲区，可在其中传递要说的文字。如果收到一条断言消息，则在追加新消息之前，只需刷新缓冲区。这意味着大多数屏幕阅读器都不知道他们是否在讲话（这包括NVDA和JAWS，这是我的主要目标受众），因此对于这些IsTalking来说，它们总是会得出false。
因此，检查屏幕阅读器是否在讲话，等待它停止，然后发送下一个消息。
我想到的另一个解决方案是两个消息之间的延迟，用户可以根据需要进行调整。屏幕阅读器会正常说话，而盲文消息会延迟发送。在主线程中实现此方法不是一个好主意，因为它将阻塞线程。但是我还没有弄清楚如何为该任务使用另一个线程。
主线程必须启动并发送盲文消息，然后休眠一定时间。
主线程必须检查另一个线程是否终止（没有阻塞！），然后发送下一条消息。
如果有人对如何实现上述解决方案有所了解，或者有其他解决方案，我将不胜感激。