Screen reader priority?
- Dominant language
- C
- Stars
- 331
- Forks
- 92
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 9
Description
Discussion started on https://mail.gnome.org/archives/orca-list/2022-April/msg00264.html
**Is your feature request related to a problem? Please describe.**
When two screen readers are running at the same time, e.g. Orca for the whole desktop and brltty for terminals, they may step on each other trying to provide the user with speech rendering.
**Describe the solution you'd like**
There should be some cooperation so that only one reader speech gets on the sound board.
One way could be to attach another level of priority to a speechd connection, that subdivides the `SPDPriority`. When a connection sets a higher priority, it prevents messages from lower priorities from being processed (and even cancels any message currently played). This is orthogonal to `SPDPriority` because for instance in terminals Brltty wants to override the normal output from Orca, but it doesn't have any notion of notification or progress, so it could prefer to let that handled by Orca or a desktop manager.
**Describe alternatives you've considered**
Orca can be made to completely shut up when switching to a given application, but that's currently a user-specific configuration that only works if brltty is running
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.