Adding an even-lower priority?
- Dominant language
- C
- Stars
- 331
- Forks
- 92
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 9
Description
**Is your feature request related to a problem? Please describe.**
from @eeejay:
“If you were listening to any other spoken words like a podcast and audio book, you wouldn't expect that media to stop or for the screen reader to wait until the media is done. The way I have seen other platforms deal with this is audio ducking”
**Describe the solution you'd like**
I don't think users really want audio ducking, since that means they don't hear what is spoken in the podcast/audio book. But if the current behavior is indeed waiting for the media to be done it can be a problem.
Among the priority categories https://htmlpreview.github.io/?https://github.com/brailcom/speechd/blob/master/doc/ssip.html#Priority-Categories we have for instance "Priority important" and "Priority message", which are able to interrupt some other priorities. Orca currently uses "Priority message", and this is probably what we want for screen reading activities. "Priority text" was rather meant for activities such as reading a whole document. When a message comes, the reading is canceled, AIUI it's because we consider that the user is stopping the read to fix a typo or something, and thus we indeed do not want to continue reading.
For a podcast or audio book, i.e. a rather background activity, these priorities don't really match: we'd want something that can be paused by screen reading activities, but not interrupted completely, so that the background reading resumes after the screen reader action.
So we could introduce e.g. a "Priority background" (or such, wording suggestions welcome!), that is not canceled, but only paused by higher priorities.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the SSIP Priority Categories linked in issue #879 and the existing handling of Orca's "Priority message" and "Priority text". Define how a proposed background priority should pause and resume without being canceled; the issue does not identify files, tests, or a settled implementation scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- audio-video-rtc
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100