Invisible Text Selection: Background Inheritance

June 27, 2007

Topics: Accessibility, Web Development.

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!

Have something to contribute?

« Read my Comment Policy

6 Comments to “Invisible Text Selection: Background Inheritance”

  1. Man, I’m starting to feel all alone on this one…I’ve been annoyed by this issue for years! And here nobody else seems to even have noticed it…

    Eh. Each to their own pet peeve, I guess.

  2. I’ve never had a problem with not being able to highlight text on a web page. Most browsers I’ve used have default background and foreground colours for highlighted text. The only time it becomes a problem is when the background colour of the page is similar to the background colour of the highlight.

  3. I’ve really never run into any serious problems using gray for my default background color. But then, what I’m using is not a custom browser setting – it’s a global Windows setting. Firefox ignores it, actually, and sticks to it’s own default.

    IE, however, uses the Windows setting. On the whole, I prefer to only have it effecting settings in IE — since I pretty much exclusively use it for testing, anyhow!

    I use text highlighting as a pseudo-pointer when I’m navigating pages with other people to help them out or explain something on the page, so perhaps that causes the issue to stand out for me.

  4. I used to use gray (great for testing at Accessites), but I ran into too many usability issues. I changed the default to #ffffcc. With this color I find that most text is more readable now, yet it still tells me in a heartbeat whether the developer has spec the background-color.

    Regarding the text selection issue you’ve mentioned is something I have either not noticed or come across.

  5. So do I – the vast expanse of white is just too bright for me. Those sorts of things really do stand out, don’t they!

  6. I have my browser default background colour set to grey, it’s amazing how many websites fail to set a default page backround themselves and rely on the default settings on people’s browsers. And it’s not smaller sites that are failing to do this, several Google and Microsoft pages have no background set which makes them really difficult to use.