<p dir="ltr">Hi Samuel and list,</p>
<p dir="ltr">The problem reported is  not a speech only problem I think.</p>
<p dir="ltr">running brltty with a2 screen  driver should only  produce speech and braille when using it in the xfce/gnome/mate/lx... terminals.<br>
Otherwise it might interfer with orcas braille output.<br></p>
<p dir="ltr">The goal with this setup is that brltty would make apps in terminal better accessible than orca. In tAt the desktop orca will do thing much better then brltty can  do at the moment.</p>
<p dir="ltr">What are the plans with the a2 driver? Do you plan to add more functionality to it to have another screenreader for desktops?<br></p>
<p dir="ltr">BR.<br>
Halim</p>
<div class="gmail_extra"><br><div class="gmail_quote">Am 08.05.2021 21:02 schrieb Samuel Thibault <samuel.thibault@ens-lyon.org>:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">----- Forwarded message from Samuel Thibault <sthibault@debian.org> ----- <br>
<br>
From: Samuel Thibault <sthibault@debian.org> <br>
To: Christian Schoepplein <chris@schoeppi.net>, brltty@brltty.app <br>
Subject: Re: Problems when using brltty in the terminal <br>
Cc: debian-accessibility@lists.debian.org <br>
<br>
Hello, <br>
<br>
Adding brltty@brltty.app since it's really not just a Debian issue. <br>
<br>
Christian Schoepplein, le sam. 08 mai 2021 16:20:35 +0200, a ecrit: <br>
> 2. Enabled speech-dispatcher support in /etc/brltty.conf. <br>
> 3. Edited the file  /etc/X11/Xsession.d/90xbrlapi and removed the "-s no" parameter for the startcommand of brltty. <br>
>  <br>
> But it seems, and that is totaly not understandable for me, that the brltty also is able to read things in ghe graphical environment. <br>
<br>
Previously, the atspi2 screen driver would indeed rather refrain from <br>
always returning content for all widgets, and rather only for e.g. <br>
terminals. <br>
<br>
But now that we have added priorities to braille output, we were able to <br>
let atspi2 always return content. But that was without considering that <br>
people would also use speech in that setup, and the problem really is <br>
that there is no way for brltty to tell speechd that messages shouldn't <br>
be actually spoken if there is another, better screen reader. <br>
<br>
The simplest would be to just add an option to make the atspi2 screen <br>
driver no always return content. Another, more complex way would be to <br>
add an option to make brltty's speech only emit messages when the screen <br>
driver reports having good quality. Another, yet more complex way would <br>
be to add to speech dispatcher a notion of overriding priority. <br>
<br>
Samuel <br>
<br>
----- End forwarded message ----- <br>
_______________________________________________ <br>
This message was sent via the BRLTTY mailing list. <br>
To post a message, send an e-mail to: BRLTTY@brltty.app <br>
For general information, go to: http://brltty.app/mailman/listinfo/brltty <br>
</p>
</blockquote></div><br></div>