Every once in a while, I come across a site with an odd problem. When I go to attempt to select a passage of text (either to highlight that section and point it out to somebody else or to copy it for later reference,) I’m unable to see the region being selected.

If I’m attempting to make a selection to copy, this is a minor irritation. It’s annoying not to have a visual representation of what I’m doing, but it’s hardly the end of the world. However, if I’m trying to point something out to somebody else, it can be rather irritating. In the context of a presentation, especially, it can be very difficult.

Why does this happen? What is it about some websites which causes them to fail to display the selection of text?

Well, the main reason is developer laziness. Yes, this is totally preventable — but it’s rarely on the developer’s list of things to check. It happens when the background color declared or inherited for a given block of text is not actually significantly different from the color of text itself. You’d think this would be very rare: after all, if you can see a block of text, then presumably the background has an acceptable background color, right?

Well, no. Not at all, actually. In fact, the color displayed behind text doesn’t necessarily have anything at all to do with the actual declared background color.

The most common circumstance to cause this problem is when backgrounds are being set using images. The background color provided by the image may contrast nicely — but this doesn’t mean that the actual color set is the same.

Recently, I was looking at a classic example of this problem. The main content of the website (which will remain nameless) had a font-color set at a medium gray shade, #747575. The visible background was straightforward and simple: white. Basic white. The text, however, did not successfully display the standard inverted color palette you’d expect when selecting text. The text did shift slightly in color (to black), but this shift was only nominally visible.

All this because the content area of this website was using an image to establish the background color, and had not set any fall back color. This meant that the background color of the body element supplied the inversion, instead: #595959. The difference between those two shades of gray is subtle. In selection, the darker gray converted to white and the lighter gray converted to black. The black was nominally distinguishable from the normal medium gray, but there was no background switch to speak of.

Had the content area of the site simply set the color to white instead of solely depending on an image, the selection would have been fine: the background would have converted to black and the text would have become white. (Actually, these colors are system configurable in Windows, but these are, I believe, the defaults.)

These kinds of problems stand out very quickly when you disable images for a site. If you disable images, and suddenly your text is extremely difficult to read because the background has vanished, then you can assume you’ll have this text selection issue as well.

In accessible web design, the possibility that images will be disabled by the user is always something I consider. As a result, I’m generally conscientious about declaring an appropriate background color and making absolutely certain that the end-value background provides an appropriate contrast to the text without any dependence on images. But this isn’t an issue which only affects the disabled — this particular case is something which can affect anybody. At the very least, it’ll be a niggling irritation on some visitors!