Signing on Server
If the user's browser cannot access a function, put the function on a server.
in authentication the user may need to provide proof of a second Authentication factor that is know known to the browser.
The browser sandbox is designed to prevent any app running in the browser context from impersonating the user in any way.
The problem that you're running into is a common one with old-style PKI systems that store the signer's private key at the boundary (eg in a smart card, a token, etc). This system was designed when the PC (and apps running on it) was the focus. But that isn't true this century. Now either the browser or the mobile is the focus.
Breaking out of the browser's sandbox
One design direction is to try to break out of the browser's sandbox to access the local hardware private key store. You've listed a number of options. An additional one is the Chrome USB access library. But all of these solutions are:
Limited to specific browsers Hard (and expensive) to install Hard (and expensive) to maintain High level of administrative overhead to help the users with their questions about keeping the system working. Re your question 5 "Any other options?"
Yes: Centralized signing
A better option (IMHO) is to sign centrally. This way the keys are kept in a centralized FIPS-secure server. Meanwhile, the signers just use a webapp to authorize the signing. The signers don't need to hold the private key since it is stored in the secure server.
To authenticate the signers, you can use whatever level of security your app needs: user name/password; One Time Password; two factor authentication via SMS; etc.
The CoSign Signature API and CoSign Signature Web Agent are designed for this. Centralized PKI signing is also available from other vendors.
Added in response to comment
From the 2nd part of your answer - If the certificate is stored in the server and retrieved by authenticating the user by using uname/pwd or with 2FA, then why do digital signing at all? i.e. what advantage does it offer over just authenticating the transaction with uname/pwd or 2FA? A: In the centralized design, the private key does not leave the central server. Rather, the document or data to be signed is sent to the server, is signed, and then the signed doc or data (e.g. XML) is returned to the webapp.
Re: why do this? Because a digitally signed document or data set (eg XML) can be verified to guarantee that the document was not changed since signed and provides a trust chain to provide assurance of the signer's identity. In contrast, passwords, even when strengthed by 2FA etc, only provide the app with signer identity assurance, not third parties.
PKI digital signing enables third parties to assure themselves of the signer's identity through the verification process. And the strength of the assurance can be set, as needed, by choosing different CAs.