The "Bad TCP" designation is seen in the coloring rules, while the "TCP Errors" designation is seen in the IO Graph. Are they the same? No. Should they be? Maybe.
Over time, Wireshark has defined the "Bad TCP" coloring rule in different ways.
Originally, Bad TCP was defined as just any packets that match the tcp.analysis.flags filter. That included TCP lost packets, retransmissions, fast retransmissions, spurious retransmissions, and duplicate ACKs. All of those items are indications of network problems. So far, so good.
The Bad TCP Coloring Rule
Over time, however, the Bad TCP coloring rule changed to exclude TCP keepalives, TCP Keepalive ACKs, and Window Updates. That was a great change since those TCP packet types do not typically indicate a problem exists on the network.
TCP keepalives are used to retain a TCP connection when no data is traveling between TCP peers. This prevents you from having to reestablish a connection when you return to the application. TCP keepalive ACKs are the response to TCP keepalives.
TCP Window Updates are good - they are a sign that there is more TCP receive buffer space available at the sender.
The TCP Error IO Graph Line
It seems to me that the TCP Error graph line (bar, actually) should match the Bad TCP coloring rule. It doesn't. TCP Errors uses a display filter for the tcp.analysis.flags items including keepalives and window updates.
A Quick Change
Do you want to exclude keepalives and window updates from your TCP Errors graphing? Simply cut and paste the Bad TCP coloring rule filter into your IO Graph TCP Errors Display Filters column.
Cheers!