It actually depends on the exact problem that is reported by the browser. You did not specify how exactly your self-signed certificate looks, so I see two possibilities (or a combination of both):
a) Untrusted certificate
The trust store of your OS holds a list of trusted certificates. Because X.509 certificates are based on a hierarchical trust concept, your OS comes with a long list of trusted certificates, so-called root certificates. Root certificates are always self-signed.
If you create a self-signed certificate, this certificate cannot be found in the trust store. Therefore, the browser issues a warning that the validity of the certificate cannot be verified.
If you agree to add an exception rule, the certificate is added to either your personal trust store or to the browser's custom trust store. As a consequence, next time the certificates is encountered, it will be considered trusted.
b) Domain or IP mismatch
When an SSL (aka TLS) connection is established, the certificate is checked against the domain name or IP address that was used to connect to the site. The domain name or IP address in the URL must be listed in the certificate, otherwise the browser warns of a mismatch.
If you override the mismatch, an exception might be added so the browser accepts the certificate for the given URL despite the mismatch. However, this type of exception is usually only valid for the current session and not stored as a permanent exception, but the exact behavior depends on the browser.