Install enough plugins on a WordPress site and you’ll soon come across some that make various style changes to make themselves stand out in the menu.

In this post I’m going to look at some examples of this, explore the reasoning behind it but also explain what the issues are with doing it.

What’s the problem?

For all of my examples, I’m using a WordPress installation which doesn’t use the default UI colour scheme. If you go into Users -> Profile you can adjust this and there are plugins that will add additional schemes as well.

Here we can see that Essential Addons has added a purple background. Not only that but with this UI the usual red background for notification numbers is not red. The fact that it shows as red here shows that they’ve hard-coded it.

This one modified one of the sub-menu colours, so that it shows in orange…

Let’s look at a longer menu list…

No-one here has changed the background colour, but Wordfence has changed the notification colour. But, here we demonstrate another issue – coloured icons. SVGs are the standard and these can be coloured in the same way that the text is. Here we see multiple plugins specifying their own, coloured icons. And we won’t even ask why miniOrange need one twice the size of everyone else!

Why is all this colouration a problem? For the reason I mentioned before – I changed the default UI colour scheme. It can be changed to anything and, rightly so, as, amongst other things, this is critical to support accessibility. However, if your plugin forces a specific colour upon the user, it breaks this. Sometimes not necessarily for the best for the plugin. See the plugin All-in-One WP Migration in the previous image? The icon is difficult to see because it clashes with the the colours that I chose.

Why do they this?

I get it. Like positioning of menus, developers do it to stand out. If your competitor is doing this and you’re not, you’re losing out. The difference here is that where the menu positioning can be annoying, the examples I give here can be serious accessibility problems.

I strongly believe that we should not accept this kind of vandalism. I’d love to see the plugin review team take a stand and not allow developers to do this.

If you’re using a plugin that has this kind of behaviour, you should consider making the developer aware of your feelings, maybe even point them to this post. If they’re not interested, vote with your feet and don’t use their plugin until they change their behaviours – using people with accessibility issues as a pawn in your marketing is just not acceptable.