One of the most famously cliched spy movie themes is the absurdly complex method (and accompanying explanation) in which the villain intends to kill the hero. Layer upon layer of killer sharks, laser beams, poisonous gases, and robot assassins employed with the sole intention of killing one fundamentally normal person (albeit a very suave person, of course.)

And, naturally, it always fails. Something goes wrong in the system; gross negligence of maintenance causes a malfunction; or some unanticipated exception allows the hero to escape.

This is an important thing to keep in mind when designing or building a web site, in every aspect. When you think you’re adding fabulous new functionality or greater accessibility, you should always be thinking about whether you’re ultimately supporting your visitor’s needs — or just making your system needlessly more complex.

Jared Smith, from Web AIM, recently published an article on web accessibility preferences expounding on the notion that in most cases, providing tools for your disabled users to change their experience usually means that you haven’t done your job right in the first place. Perhaps, rather than adding a tool to enable people to adjust your site, you should simply fix the site. Jared makes the very good point that in most cases, the people who need text enlargement have already taken care of it through their browser settings or operating system; and those who need extreme enlargement can’t be helped by a common accessibility widget — they need software support.

So, given this case, what do you actually accomplish by adding accessibility widgets to a web site?

If you’ve added them to a global element, to make them available throughout the site, you’ve made your site more complex: there’s more information on every page which needs to be sorted through or skipped over. You’ve added an additional technical element which needs to be supported and maintained — as browsers change, you’ll need to be rechecking not just your default settings, but all of the various combinations you’re providing, as well.

If you’ve added the same options to a page dedicated to these accessibility options, you’ve pretty well avoided the problem of having a globally more complicated interface. However, you need to ask yourself whether the problems your accessibility options fix will prevent the users who need them from finding the options! Take this example: you’ve chosen a relatively low-contrast (but attractive) text color for your footer and secondary header navigation. Since this color is below the WCAG 2 color contrast requirements, you’re providing a link to a page where the user can select a high-contrast option.

Unfortunately, since the link is in your footer, that user who needs a high-contrast page can’t actually find the page where they can make the change.

Problems with site complexity don’t only effect web accessibility, however. Any additional function to your web site needs to be carefully considered before implementation: is it worth while to add an audio player with auto start to your home page? What are the consequences of making this change? You may think that it’s a great opportunity to immediately promote your band’s music to those who want to hear it; but you’re making the gross assumption that those visitors want to hear it right now. They may not. And if they’re in a sensitive situation — checking you out from their quiet office cubicle, for example — then their first reaction is likely to be “How do I turn this off!”

Assuming you have decided to add this audio player to your web site — you may not realize that the most important control you need to have is a prominent STOP button. Otherwise, the most natural way to stop the music is to leave your site.

Any piece of new functionality adds complexity to a site. It may create an undesirable reaction, it may create user confusion — or it may be a brilliant idea which turns your home business into a multi-million dollar corporation. You shouldn’t avoid adding functionality on the grounds that anything complicated is going to be a problem; but you should certainly take a very close look at every new feature and decide whether it will add to the user experience. When making that decision, the points to consider are not limited to the value of that feature alone. You need to also consider all the other features which will be simultaneously available; you may want to add a new feature, but move an existing one. It’s usually not any given feature which causes problems; it’s having too many paths to follow which may confuse your visitors.

The United Kingdom-based Royal National Institute for Deaf People (RNID) recently produced a nice mini-site entitled “10 Things You Should Know About Web Accessibility.” For the most part, it’s excellent — a friendly voice, a casual approach, elegant presentation, and good information.

It does, however, intimate one of my pet peeves in documents promoting web accessibility:

Hey good lookin’

“But accessibility always compromises the design, doesn’t it?”

Wrong. Your site can still look beautiful.

This doesn’t precisely say that compromise is not required for accessibility; but it’s certainly implied by the language chosen.

To suggest that compromise is not required is simply a mis-representation of the truth about accessible web design: you do have to make compromises. Whether they’re compromises concerning how information is presented, the color contrast between elements, the specific uses of language or technology, you have to make compromises.

The perception seems to be that making compromises for accessibility means that you create an unattractive web site or otherwise decrease the aesthetic value of your web creation. This is not true: but it’s inaccurate to say that you don’t make compromises.

Truth: Effective accessible design has requirements which will require compromise in many areas.

It’s important to educate all participants in a web design project on accessibility before any serious work is done, to help prevent problems. If the designer knows to check contrast levels before proposing a design, they’ll start by creating an aesthetically elegant design with the color palette available. If they aren’t aware of these problems, you’ll end up making compromises on colors — and, without extensive modifications, it is entirely possible that these compromises could have a damaging effect on the aesthetics of the site.

Compromise shouldn’t damage aesthetics or accessibility: but poor planning almost certainly will.

At least, in the final reckoning.

Something which comes up over and over in my work is the tendency of clients to request design changes which I don’t particularly care for. This isn’t to say that they’re ugly, per se — after all, the fact that I don’t like them isn’t actually equal to “ugly.”

Early on, I would argue with clients concerning these design changes — try and get them to see my perspective, etc. But the fact is that aesthetics are not objective. Opinion matters; and it’s ultimately the client’s decision.

Now, I only argue with decision which cause problems. You want that to be blue instead of green? Fine. Doesn’t matter to me that it’s going to clash with the rest of the color scheme. But you want that text to be blue against an orange background? That, I won’t do. That’s the kind of decision which will render the text unreadable — and I’m not willing to do it.

Occasionally in my consulting practice I encounter designers (or stories about designers) who are so wrapped up in control over their design that they barely consider the client’s needs, let alone the needs of usability and accessibility. That’s unfortunate; since in the end, what your website looks like just barely registers for many visitors.

I sincerely believe (unscientifically) that most visitors only notice website design in one of three ways:

1. The design prevents them from effectively using the site.
2. The design is absolutely spectacular.
3. The design is absolutely horrific.

Do you really want your design to be attracting attention? Certainly not for reasons numbers 1 and 3, and although the second reason is positive, it’s not necessarily best for every site. Incredible design doesn’t necessarily support your business in the best way; it could just get in the way. This can’t be decided universally, of course — and it’s never a bad thing to strive for a great design.

It’s hard to ask questions about whether people noticed the design of a site. After all, it’s rather a quantum query: once you’ve asked, they will observe. The act of asking changes the experience of the visitor. Even in a usability test, it’s hard to identify this observation. Even though you can set up the scenario more effectively, if your testers are still aware that they are testing the site, they will tend to be more observant than otherwise.

You can’t TELL somebody to just “act normally” during a test, unfortunately. It doesn’t work that way….

Nonetheless, the rules I will work to avoid are clear: don’t make it horrible, and don’t let it get in the user’s way. Otherwise, what it looks like is open territory. I’ll try to make it look as good as I can, but if a client wants a change — they’ll get it.

At Cre8asite Forums this week, a lengthy discussion on the ultimate value of pure CSS (Cascading Style Sheets) based layout over the use of tables has been taking place. Sometimes, living in the sheltered world of accessible and standards-based design, I can lose touch with the fact that many people out there simply don’t accept some of the same guidelines I work with every day — and that this does not, in any way, mean that they haven’t given the subject a fair shot. Very good arguments have been made to defend each side.

On the whole, I think this discussion is an old, worn-out subject: those who won’t use tables generally don’t use them out of principle, and those who do use them out of pragmatism and a justified awareness that principles don’t build websites. I want to review the question once more, however, ignoring the entire question of principle.

Read more: Why not tables? Is CSS really better?