Self voicing apps utilising nvdaController will be broken after changeset:main,5298

[nvaccessAuto]

Reported by Palacee_hun on 2012-08-02 11:11
NVDA will ignore output coming from nvdaController functions when sleep mode is active after 29ec231. This will cause serious problems.
[take the popular Klango Player as an example. This is a self voicing app that uses NVDA as its output channel (if running) among others. It achieves this most probably by using nvdaController functions. In order to inhibit the regular screen reading functionality of NVDA while Klango is running and thus to avoid double speaking and other adverse side effects, Klango appmodule (part of NVDA distribution package) turns on sleep mode for Klango. This was very fine before 29ec231. But Klango won't work this way after this changeset, because direct speech requests from it will be ignored, and Klango would be silent!
[[BR]([BR]]
Let's)]
Klango isn't the only example for this serious breakage by far. I am afraid 29ec231 ruins the original logic behind sleep mode. Sleep mode was designed to allow self voicing apps to directly output their messages through NVDA so that they wouldn't be interfered by the regular NVDA screen reading functionality. It's very easy to see that this isn't possible after this changeset any more. I think this changeset is the continuation and sort of consequence of the recent "lock screen fix", but I am afraid this is not the right track. Please rectify this as soon as possible and please ensure that excellent self voicing apps do not get crippled by this issue. Thanks much in advance and keep up the good work!

[nvaccessAuto]

Comment 1 by jteh on 2012-08-02 11:19
Actually, sleep mode was originally designed for self-voicing applications, but not applications which speak via NVDA. That is, it was designed for applications which provide their own speech. There are quite a few apps which do this; !OpenBook is one example. NVDA is literally meant to go to sleep. (It should also release the braille display for use by the application, but it doesn't currently do this. If we supported external synths, we should also release those for use by the application.)

This problem suggests we need two different sleep modes: one to just suspend screen reading functionality and one to suspend everything.

Do you have any knowledge of how other screen readers handle this when their equivalent of sleep mode is enabled?

[nvaccessAuto]

Comment 2 by elliott94 (in reply to comment description) on 2012-08-02 12:21

[nvaccessAuto]

Attachment ScreenReaderAPI.zip added by Palacee_hun on 2012-08-02 13:27
Description:
Universal Screen Reader API and Test Programs

[nvaccessAuto]

Comment 3 by Palacee_hun (in reply to comment 1) on 2012-08-02 13:45

Do you have any knowledge of how other screen readers handle this when their equivalent of sleep mode is enabled?

[to [comment:1 jteh]([BR]]
Replying):
[[BR]]
Unfortunately not, and I don't have any other screen readers besides NVDA to test myself. But to facilitate examinig this, I've attached a little package made by Quentin Cosendey, the author of QuentinC Playroom, an online gaming platform that talks to the APIs of multiple screen readers to achieve high degree of accessibility. There's a DLL in the package and some test programs for it and header files. The DLL enables the programmer to directly output strings to 5 major screen readers (plus SAPI5) via an unified interface that is very similar to nvdaController. It also autodetects the running screen reader, and falls back (if told so) to using SAPI5 if no supported screen reader was found. Unpack the attachment, and run e.g. the test Python script under other screen readers. It should speak a message. Then enable the equivalent of sleep mode, rerun the script and see what happens.

[nvaccessAuto]

Comment 4 by jhomme (in reply to comment 1) on 2012-08-02 16:17
Hi,
My experience tells me that sleep mode totally turns off speech in other screen readers. I think that I like the solution you proposed, Jamie, in which NVDA might still be able to talk under various circumstances.
JimReplying to jteh:

Actually, sleep mode was originally designed for self-voicing applications, but not applications which speak via NVDA. That is, it was designed for applications which provide their own speech. There are quite a few apps which do this; !OpenBook is one example. NVDA is literally meant to go to sleep. (It should also release the braille display for use by the application, but it doesn't currently do this. If we supported external synths, we should also release those for use by the application.)

This problem suggests we need two different sleep modes: one to just suspend screen reading functionality and one to suspend everything.

Do you have any knowledge of how other screen readers handle this when their equivalent of sleep mode is enabled?

[nvaccessAuto]

Comment 5 by pitermach on 2012-08-02 16:29
Replying to jteh:

Do you have any knowledge of how other screen readers handle this when their equivalent of sleep mode is enabled?

Sleep mode in JAWS was weird, in that enabling sleep only seemd to suspend screen reader keyboard processing, but you still had speech and braille, in the API as well. Muting the speech was a checkbox next to it, but braille still worked.
Supernova doesn't have a sleep mode, but if you turn speech and braille off, API messages are still spoken. This is really nice, because if I was checking things in Klango I could still hear tweets, and Skype messages coming in. That's what NVDA used to do, and I personally am not a fan of this change myself.
Another thing. Some apps, in addition to speaking things through screen reader output still open windows on screen, which can cause unnecessary double speech, which you could avoid by turning on NVDA's sleep mode, and keep playing. Entombed is an example of this, where entering some menus and shops displays actual buttons and lists on-screen.

[nvaccessAuto]

Comment 6 by jteh on 2012-08-03 06:29
In 0100a8c, I've reverted sleep mode to the way it was before; i.e. controller client messages are still presented. This is debatable as noted in comment:1, but it seems some apps already depend on this functionality.
Changes:
Milestone changed from None to 2012.3
State: closed