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?