@BoundTo:
The easiest thing is to put all the Tolk dlls in the same folder as your .exe file.
If you don't like doing that, you can create a config file that sits by your .exe file and tells the .exe file where to find dlls.
It must be named with the exact name of the .exe, with an extra .config extension on the end.
So MyProgram.exe would get a MyProgram.exe.config file.
That file would contain something like the following:
<?xml version="1.0"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="lib;lib\Tolk"/>
        </assemblyBinding>
    </runtime>
</configuration>
That tells it to look in the lib and lib\Tolk folders for dlls.
This makes it so the Tolk.net.dll and the tolk.dll can be placed in the lib or lib/Tolk folders.
Unfortunately the other dlls still have to be in your main .exe folder, unless you modify Tolk and rebuild it.
What happens is that your main program is running in the .NET framework, so it reads that config file and finds tolk.net.dll in the lib/tolk folder.
Then tolk.net.dll is also running in the .NET framework so it uses the same configuration to find the native tolk.dll in the lib/tolk folder.
Then the native tolk.dll tries to find nvdaControllerClient32.dll and others, but since it is native, it doesn't know/care about that .NET config file, so it looks in the current working directory, which is usually the same folder as your .exe file.
So to recap, though there are ways to get around it, it is just much easier to put all the dlls you need in the same folder as the .exe file.

Just FYI, I personally use Windows Forms to create the basic window and capture keyboard and mouse input, but I do not use all the windows forms controls when making games.
I usually just output through tolk for games.
I also use my own UI library that wraps UIAutomation and relies on some basics from windows forms, but that is more for general applications that need good textbox support and such, not for games.
You could certainly use normal windows forms controls if you were going to make a general application, or if you need a textbox for brief periods in your game.
You can use XInput and DirectInput wrappers to get gamepad support.
You can use a windows forms timer to implement an onTick/update method that runs many times a second.
It cannot run as often or as accurately as a separate thread, but it should be plenty for audio games, and it runs on the same thread as all your windows forms logic, which lets you avoid cross thread issues.

I noticed a couple unfortunate  things when using MonoGame in the past.
One was that if you alt tabbed away from the window and left it for a little while, the MonoGame window would start to consume all of one CPU. I'm not sure why, and perhaps it has been fixed in a more recent version.
The other was that MonoGame will crash on startup if someone is using an unsupported video card driver, even if you are just displaying a blank window.
If you are only building audio games, it is unfortunate to have some blind players excluded from playing due to a video driver or video card issue, since it seems pretty unrelated.
I haven't had those problems with windows forms, which is one reason I still use it.
I haven't tried SDL and other game libraries, so they may work well. I'm not trying to sway your decision of which libraries/frameworks to use, just trying to share some of my own personal experience for what it is worth.
Hope some of this is helpful.

Edit:
If you use windows forms, you should use this line in your form constructor:
this.KeyPreview = true;
It makes it so your form will get to see key events before other controls. Otherwise other controls can intercept and mark them as handled so the form never sees them.