[BRLTTY] Should the graphical BRLTTY speak if the text one does?
Sébastien Hinderer
Sebastien.Hinderer at ens-lyon.org
Sun Oct 5 07:29:18 UTC 2025
Dear all,
As you all probably know, if one uses graphical terminals then two
instances of BRLTTY are running: one thatfollows text consoles (Linux
screen driver) and has the real device driver as its braille driver, and
a second one with AT-SPI2 screen driver and that uses the "virtual"
BrlAPI braille driver to send the text to be displayed to the so-called
root BRLTTY.
At the moment, if the graphical BRLTTY is started by the script that is
called when the X server is loaded, then that graphical BRLTTY will not
speak, even if the root, text one has been configured to speak. This is
achieved by adding "-s no" to the command-line used to invoke the
graphical BRLTTY.
The reason why this is so is because there is no way at the moemnt for
BRLTTY and another screen reader like Orca to negociate who is going to
render some content through speech, whenthe two assistive technologies
are able to render it. This differs from braille where BrlAPI hase
a priority mechanism that lets BRLTTY take precedence over Orca as far
as rendering braille is concerned.
So the question is, according to you all, how should we proceed.
Enforcing "-s no" for the graphical BRLTTY can result in counter
intuitive experiences if BRLTTY has been configured to speak in text
consoles, but currently in absence of "-s no" both BRLTTY and Orca will
render the content of the terminal through speech synthesis until Orca
is configured not to do so, but this will require a manual configuration
fromthe user.
Thanks for your insights,
Seb.
More information about the BRLTTY
mailing list