There's no gray zone about it, when your work entirely depends on another software product to function, that's pretty clearly established to be a derivative work. If you've created a derivative work from something you do not have a license to derive from, then you're wide open to claims of copyright infringement and possibly other things.
Once you start making money from this product, your problems just get worse. Imagine if I made an app called Toogle Mapz and all it does is hide Google maps in the background and provide a different UI to expose the function of Google maps to the user. It's pretty clear when you start to think of it that way, and even this isn't a great example because Google will actually give you API access to essentially accomplish this, but let's pretend they don't do this. You know full well that Google would have the legal department ripping down your app in a heartbeat at the very least.
Dale gave a good answer, I just wanted to be clear though that there is also this angle, and that's regardless of what the EULA says (assuming that the EULA does not grant you a license to create derived works). It's copyright infringement. Plus, you have no idea if there's functionality inside the code that your code relies on that is patented, and then you could double up your problems with patent infringement. Unless you've been given a license to do this, don't do it.
If you can provide an alternative UI, say for example on Android, by making an application that controls accessibility features, and you apply these features through the system in a generic way without being intimately bound (tight coupling of dependency on) to the target application, I'd say you'd be fine. But grabbing a handle to the app, shoving it in the background and hard-coding your application to be tightly coupled to the target app would make it a derivative work for sure.