nvda
nvda copied to clipboard
nvaccess
Create NVDA's com object as NVDA Controller library equivalent
Consider creating an NVDA's com object (OLE Automation) that will register with the system when NVDA is running. This com object should provide an API for interacting with NVDA. In particular, the speak text and the output text on the braille display.
There is currently the NVDA Controller library. It allows to implement this functionality. However, the implementation based on the com object seems to be more convenient.
The library should be included in the application or framework that needs to use the API. Often this is difficult or impossible due to the licensing policy of the application or framework. Including an external component with a separate license requires complex negotiations and is not always possible. To date, developers of the accessibility layer in the Open JDK have already encountered such a problem.
If NVDA, at startup, registers a com-object with an API in the system for interacting with NVDA, then any application or framework will be able to implement the necessary methods for interacting with NVDA. For example, methods for sending announcement messages.
Often this is difficult or impossible due to the licensing policy of the application or framework. Including an external component with a separate license requires complex negotiations and is not always possible. To date, developers of the accessibility layer in the Open JDK have already encountered such a problem.
I'm not sure the solution described here will address this particular problem. It would be helpful if you could elaborate on this licensing problem further.
There are other benefits to a COM API, but for us this isn't a high priority because generally the NVDA controller library approach seems to cover the usage requirements we are aware of.
@feerrenrut Hi. We would like to implement the ability to announce messages through different screen readers, including NVDA. But we can't use external binaries for security and support reasons. We can either use the com client's native source code for self-assembly within our project, or the com com object.
@savoptik You'll need to explain how this provides value for NVDA users generally. If you aren't sure how to do this, start with describing one concrete use-case that helps NVDA users.
Otherwise, I'd suggest building your own communication layer to achieve this.
If your company would like to consult with NV Access about this work, please contact [email protected]
Creating a COM object isn't that trivial and breaks backwards compatibility in a major way. We'd still need to support the old API. Also, having to register the COM object imposes some challenges with portable copies. I'd be very reluctant to do this.
Cc @OzancanKaratas
@leonardder, potentially, we register the COM object when NVDA is started and unregister it when it is closed. Can this option work on a portable copy?
It is technically possible, but even on installed copies, every client will have to recreate the com object when NVDA is restarted. I consider that a major drawback of the approach.
I thought we might have a better approach. We can distribute the controller client files together with NVDA rather than providing them as a separate copy. So each developer calls the controller client from the NVDA directory.