Most real world examples that I have found are either too simple or too complex to fully explain here. I would recommend looking at BlackWasp’s articles on SRP. (Much of the content of that site can be summarized as shown below.)

From the man who created the term Single Responsibility Principle:

… This principle is about people.

When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.

Why? Because we don’t want to get the COO fired because we made a change requested by the CTO. Nothing terrifies our customers and managers more that discovering that a program malfunctioned in a way that was, from their point of view, completely unrelated to the changes they requested. If you change the calculatePay method, and inadvertently break the reportHours method; then the COO will start demanding that you never change the calculatePay method again.

He goes on to later re-state the SRP in simpler terms:

Another wording for the Single Responsibility Principle is:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

Wikipedia has a simpler definition:

In object-oriented programming, the single responsibility principle states that every context (class, function, variable, etc.) should have a single responsibility, and that responsibility should be entirely encapsulated by the context. All its services should be narrowly aligned with that responsibility.

Which specifically tells you that you can have a class that causes multiple other changes, based on interaction with the specified class (or button).

It goes on to give the example of a report class:

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

I agree with Ampt’s comment:

^{If you assume that the buttons responsibility is to take in user input and call the appropriate method, then you aren’t violating the SRP.}

In your case it would be more important to distinguish between functionality and presentation – to separate the GUI and the code that is run when clicking the button. Event handling is part of the GUI, so it can stay there, but coupling the actual functionality of the button to the GUI I would not recommend.

This should be your SRP focus in this particular case. As it often is with SRP, keeping presentation and code apart can be very helpful. There’s a reason architectures such as MVC are so popular.

Your button class does do just one thing: it manages the state of the button. The fact that the button can do multiple things or has multiple behaviors has no bearing on the single responsibility principle.

Where the principle comes to bear is in the implementation — if the button has two behaviors, each behavior should be through a different method. Don’t create one method that handles both through a series of if statements.