Our most definitive insight comes from one of our customers, and is as follows: they went through the list of running Windows processes for potential culprits. Among them was a service as part of “Plantronics Hub” which is software for controlling how bluetooth headsets work with applications. Our user removed this (and several others).
Our user doesn’t know for sure if it was the Plantronics software, but after removing it the unwanted narration is no longer present!
Anyhow - hoping this feedback is of help.
Thank you very much for keeping on improving JUCE!
I’d like to follow up on this issue. I am receiving reports of users reporting the SAPI-based announcements running even when their narrator instance is off.
Given the fact that SPI_SETSCREENREADER doesn’t report wether Narrator is on or off, one solution would be to check if the narrator mutex is running like mentioned here by abudker.
Additionally, one quick workaround/feature would be to add the option to set the annoucements level within AccessibilityHandler::postAnnouncement (const String &announcementString, AnnouncementPriority priority, int volume = 100). This would require to simply add a call to ISpVoice::SetVolume() within the native juce_win32_Accessibility.cpp file.
This fix would also give the option to impaired user to edit the volume of the SAPI announcements given the fact there is no way to set the sapi volume in the “Speech Properties” menu in the Windows control panel, at least on my machine.
We’ve had a report of something similar from one user: narration happening even when narrator is not running. I’ve asked them if they can also try things in safe mode, and potentially try to pin down which process (if any) might be at the root of things.
The user that we were in contact with found that there was a registry key that was causing the problem, even though Narrator was deactivated in the preferences: