You are reading an archived post from the first version of my blog. I've started fresh, and the new design and content is now at

The Meaning of Web Standards

September 14, 2005

Imagine, if you will:

As part of this web standards and accessibility consulting project we’ll produce a document that guides your work so your developers are ‘doing the right thing’
That’s excellent – really good value and great for our redesign efforts
No problem. Let’s make it happen
Yes. Let’s.


Here’s the wonderful guide we’ve produced for you that outlines web standards and accessibility and their role in your organization
This sucks. All it tells us is what we should be doing, but doesn’t give us enough detail. We want you to tell us what to do
Well, that’s what’s in there – it tells you what to do
No, it doesn’t
Oh. (thinking) Crap

OK, OK, this is fictional – but based on experiences consulting in web standards and accessibility.

How did this all happen?

In the world of the blogger/standardista/whatever-we-are, web standards generally means a few things – semantic goodness, building sites/applications that use technologies they way they were meant to be used, building things with a 3-legged stool (HTML, CSS, DOM Scripting), and, of course, making sure that what we produce is accessible.

That is what web standards is – a set of strategies and tools to build our web sites that do what it is we set out to do – whether it be a hobby site, a paid site on contract, or part of our job as an employee.

At least, that’s what it is to us. You know – us – the 3% of the web developers out there that know about this kind of thing. The 3% of web developers/designers that follow blogs, online zines, and the various mailing lists that comprise our daily web intake.

In much of the web standards and accessibility work I’ve done, I’ve noticed that when I talk about Web Standards to others, sometimes we’re talking completely different languages, and it can be the source of much confusion – here’s why.

To the other 97% of people out there (especially people that aren’t developers) Standards are, well, standards – measurable rules or qualities that can be held up as a comparison. The closest web standards comes to that is validation – its about the only thing that can be measured. (No, this is not an open invitation to start the validation debate)

Using the term web standards has been the source of confusion in the past – when I’m talking to managers and other people about web standards, I’m talking about an overall strategy for development, and they (often) are, or want me to be, talking about things that typically go in a style guide – rules that state “Images on our site shall be no wider than 600 pixels” or “Link text must not use the phrase ‘click here’.”

The difference? One is strategy-based and focuses on the macro level, the other is rule-based and focuses on the micro level. The two are complementary (or can be) but aren’t necessarily synonymous.


The problem really becomes one of expectations – if you are writing a document “Web Standards at Department/Company XYZ” are you writing a strategy document or a rules document? That is really where the distinction becomes clear. A 5 page document becomes a 50 page document, and for many reasons, that’s not so good.

Has anyone else out there had this happen to them? Are there other interpretations of “web standards” you’ve run across that have caused confusion where two parties are looking at the same “thing” in a different way?

Filed under:

10 Responses

Comment by Jesse — Sep 14 2005 @ 3:11 pm

I am living in that confusion and trying to work through it. I find the confusion comes from the different type of ‘standards’ that people conceive and bring to the table.

People generally seem to relate web standards to the type of standards they deal with daily. Often people view them as rules that aren’t to be broken. A template that is always the same and applied to every situation no matter what. But web standards in practice seem to take their lead from the publication world. People in the publication don’t have a problem with that type of standards document, but most people tasked with maintaining a web site or creating one are not from the publication world — especially in the public sector.

For instance a writer will perceive a ‘writing style guide’ as ‘standards.’ Writing style guides are fairly vague but need to be as they aren’t writing stories for people but just letting them know that Quest is referred to as Quest not QUEST. Mark-up standards are very similar.

People seem to want a rules document with regards to web, they can’t handle the strategy. I do enjoy watching people’s eyes glaze over when I say ‘ok, why are we creating this web site, for whom are we creating it, and who is going to maintain it, and how are they going to do it?’ They just want ‘lets build.’ Maybe it is the instant gratification of web publication and lack of monetary commitment that fuels that attitude?

Comment by Richard Farmer — Sep 14 2005 @ 3:39 pm

I recently started work for a small S.E.O. / Web Design company in the city where I live and feeling quite confident about web standards myself, following as I do, most blogs, and knowing most authorities on the subject, I was quite shocked to find the technical development people there; blissfully unaware of any kind of standards what so ever, in fact these people are not connected to the developer community / blogosphere at all. They are happily stuck in about 1998 where I.E. is king, PageRank is God and Validation is a chargeable service.

It really amazes me how people can go about their jobs knowing so little about the internet and the standards designed to make it better.

Kind of a slightly off topic comment, but its good to remember that even if you know a little about standards, its probably more than they know at the big local company in your area.

Comment by Dustin Diaz — Sep 16 2005 @ 11:58 am

I somehow got an entire group off track thinking that web standards just meant replacing tables with divs… and since everyone wants a short and simple answer, that’s what they came away with.

In the real world, clients don’t care about standards and it takes a real convincing argument… so I generally take the “semantic” route letting them know that it allows for better seo which brings in more dollars for the business. Yes, semantics, finding the right tag for the appropriate content.

For engineers, I usually tell them “it’s like xml” – so don’t think of html as a presentation language, but a data storage language.

For mom and pop, well, they wouldn’t understand, so just let us do our job.

Comment by Jens Grochtdreis — Sep 16 2005 @ 4:50 pm

Yes, Derek, you are right. In my view the most important problem we standardistas have to face today is to find the correct language for talking with the clients. We must tell them in their language how they could detect a good website. And why a mostly valid page is worth trying. I say mostly because I don’t think that it is really important to have zero erros in the validator. It depends on WHICH errors they are. Do they destroy the page or are they irrelevant like the & in a url?

Only if the clients can detect quality the web will make a bigger step forward.

Comment by rich — Oct 01 2005 @ 12:25 pm

Good article :-)

I’ve been working for a university for about 9 months, and I too had the unpleasant experience of discovering that nobody had any idea what ‘web standards’ referred to, or what the point of any of this was.

These were people who saw nothing wrong with things like:

<tr bgcolor="000033">
<td valign="middle" bgcolor="000033">
<font face="arial, helvetica, sans-serif" color="ffffff" size="2">
<p class="bluetext"><h2><b>Welcome</b></h2></p>

…and much worse. (Sorry – I don’t want to think about it.)

To the main site editor, web standards meant pointless dedication to the W3C guidelines, and religious validation with no goal. He saw no benefit to these ideas (rightly, in many ways) and so basically stuck with tables and dodgy code… because the alternatives, as he saw it, were simply arbitrary and too much work.

It took me many months of gradually showing him the kinds of improvements that could come from a clean, flexible, semantic approach (you know the drill) before he agreed to me redesigning the main template.

Now, I am working fast to quickly trash all the old templates and get the new (and much better) versions in there.

I think I read Zeldman point out the moral of this kind of story a few years ago: you often can’t win this kind of debate by saying “you need to adopt CSS and XHTML and semantic code and the rest of this 3-legged stool thing because it’s got all these advantages”. Instead, you sometimes need to just show people how much faster development can be, and how much more flexible design changes are, and what cool things you can do with neat graphics and the DOM and so on.

It’s been quite a long term thing for me, making changes and working overtime so that things just got better. I could then show the editor how I did it, and it would quietly win him over. I’m not sure I could have persuaded him in a single meeting, and in fact every time I tried, we would end up having arguments.

Comment by Ian Lloyd — Oct 03 2005 @ 4:52 am

Some people don’t like to be handed a document that spells things out simply. If you can document everything on a few sides of paper, then you’ve done a good job, say I. But clients, well, they only feel like they’ve got their money’s worth if they’re handed a 50-pager (that they’ll never read or digest). Clients, eh? Can’t pay the bills without ’em, illegal to shoot ’em.

Comment by neil — Oct 08 2005 @ 11:52 pm

Personally, I try to avoid using any web-related jargon or terminology with clients if I can help it. Instead of web standards, I say “industry-recognized methods”. Instead of information architecture I say “organizing and structuring your web site”. Instead of usability I say “user-friendly” (which isn’t awesome, but at least is fairly well understood by now). Etcetera.

In my opinion, most of the terminology we use in our industry is just pretension. Too many people use jargon because it’s a short cut to explaining in plain English what you’re actually going to do.

A certain level of language specific to our industry is understandable and important, but I think unless the client is obviously tech-savvy, the less jargon, the better.

Comment by Johan De Silva — Nov 16 2005 @ 5:00 pm

I follow web standards for my career, but the fact remains that the web is(or was) all about the average Joe writing a website without much technical knowledge. Following WC3 standards requires you to step into the geek's world so I hope future devises will still continue work with non valid mark-up"┬Žso what's the point of doing standards it in the first place?

Comment by Kevin — Dec 06 2005 @ 6:06 pm

This is what usually happens… not only with webdesign, but with copywriting, pr consulting etc. They always forget ’bout what they have sad last time… but they are the clients :mad:

Comment by Anita, web developer — Dec 14 2005 @ 3:20 pm

I know I know… communication between client and us is sometimes very difficult. But remember who is always right. We are forking to make them happy first of all.