Does the Singleton really violate the Single Responsibility Principle?

On the Singleton page, it says:

The Singleton pattern solves two problems at the same time, violating the Single Responsibility Principle

This view is echoed by the article Why Singletons are Evil, which writes:

2) Singletons allow you to limit creation of your objects.

This is true, but now you are mixing two different responsibilities into the same class, which is a violation of the Single Responsibility Principle.
A class should not care whether or not it is a singleton. It should be
concerned with its business responsibilities only. If you want to limit
the ability to instantiate some class, create a factory or builder
object that encapsulates creation, and in there, limit creation as you
wish. Now the responsibilities of creation are partitioned away from the
responsibilities of the business entity.

However, I don't think singletons violates the Single Responsibility Principle (SRP).

As clarified on the The Single Responsibility Principle article, the Single Responsibility Principle is "about people", and "responsibility" defined as a (business) "reason for change". A reason that the code for accessing the database may change is if the type of database use changes, but having a single pool of connections (enforced by the singleton) and making it available is, to my understanding, two separate technical requirements but a single business responsibility.

Would love to know your thoughts!