An analysis of my problem.
Blind people use a screen reader to interact with applications. These screen readers speak contents, messages and the like at the preferred speech rate and other settings. From the developer's point of view there are some convenient features as well: When passing text to a screen reader it can be assertive (so interrupt the screen reader) or polite (the screen reader finishes the reading of the current text before moving onto the next text).
Some blind people (or deafblind people) additionally or solely use a braille display, however. A braille display (ideally) displays the text the screen reader is reading, or a suitable version of it. In reality, many screen readers deprive braille display users of certain info if they don't configure their braille displays to read through the screen reader log instead of viewing the current application.
I'm creating an audio game with braille support. Which is in itself unusual - most audio games are just that: audio.
My first problem was how to get the screen reader to speak messages and simultaneously pass them to the braille display. The solution to this was the Tolk screen reader abstraction library
It works as advertised, but there's a problem tolk can't fix: Braille messages get sent way too fast. Due to the implementation of braille messages in many screen readers (if not all), if two messages get sent one after the other, they arive almost at the same time, giving the user no time to read the first message before the second appears (if they notice the first message at all).
In Tolk, there's a function Tolk_IsSpeaking() which returns true if the screen reader is speaking and false if not OR if the screen reader does not implement such a function.
And that's the main issue: Most screen readers have a buffer in which the text to speak gets passed. If an assertive message arives, the buffer simply gets flushed before the new message gets appended. That means most screen readers don't know if they're talking (this includes both NVDA and JAWS, which is my main target audience), so for those IsTalking will always evaluate to false.
Hence, checking if the screen reader is talking, waiting for it to stop, and then sending the next messagoesn't work.
The other solution I thought of is a delay between two messages which the user can adjust as needed. The screen reader would talk normally, while just braille messages get delayed. Implementing this in the main thread is a bad idea as it will block the thread. However I haven't figured out how to use another thread for this task.
The main thread would have to start and send a braille message, then sleep for a certain amount of time.
The main thread would have to check for the other thread to terminate (without blocking!) and then send the next message.
If anyone has an idea how to implement aforementioned solution or has a different solution in mind, I would really apprciate it.
