Problems with Using Website Validation Services

Jun 7 2010 by Alexander Dawson | 27 Comments | Stumble Bookmark

Amongst the basic skills that fledgling designers and developers should know is the art of website validation.

Website validation consists of using a series of tools such as W3C’s Markup Validation Service that can actively seek out and explain the problems and inconsistencies within our work.

While the use of such tools has benefits (in the sense of being an automated fresh pair of eyes), a worrying trend of either over or under-dependence keeps rearing its ugly head.

This article aims to underpin the inherent issues of validating your websites through automated web services/tools and how using these tools to meet certain requirements can miss the point entirely.

Current Practices

Before we begin critiquing the valiant efforts that our noble code validators undertake (they have good intentions at least), it’s important to note that with all things in life, a balance must be struck between the practical application of validation and common sense.

We live in a modern era of enlightened thought where web standards have become a white knight, always charging towards slaying code which fails to best represent our work.

But while current practices actively request and promote using these validation tools, no web-based tool is a substitute for good judgment.

Current Practices The above code may not validate, but it’s acceptable to use if there’s no good alternative.

Not Using Valid Code

The case for under-dependence can be seen by examining the Alexa Top 100 sites and using some basic W3C validation tests.

The eye-watering number of errors these popular sites produce (which escalate into the hundreds) is rather unsettling for some.

The problems for those ignoring validation altogether has been well-documented to the detriment of end users (as has the justification for following web standards) and as ignoring validation entirely makes you as guilty as those using it as a crutch, it’s worth recommending not to forsake these tools even with their shortcomings.

Amazon's front page doesn't validate, but it doesn't mean they don't care. Amazon.com’s front page doesn’t validate, but it doesn’t mean they don’t care.

Blindly Following the "Rules"

The case for overdependence is something we need to worry about too. Those who form drug-like addictions to making everything validate or meet a certain criteria just to please an innate need for approval are on the rise.

While ensuring your code validates is generally a good thing, there are professionals who take it to such an extent that they resort to hacking their code to pieces, ignoring new and evolving standards or breaking their designs just to get the "valid" confirmation. Quite a price for a badge.

And there are even people who think validation automatically means everything’s perfect, which is worse.

There are a lot of tools out there, but you should be wary about which you rely upon.

Context is King

The thing about validation tools that beginners (and some seasoned professionals) often overlook is the value of context.

The most common problem that validation tools encounter can be summed up in the sense that they are only machines, not humans.

You see, while checking if the code you wrote is written correctly, on the surface, may seem like a simple task, that sites meet disabled users’ needs, or that text on the screen is translated properly — the very obvious truth (for those who understand the mechanics involved) is that the complexity of how humans adapt cannot be replicated effectively.

What does this design say to a machine? Nothing! It only sees the code and that’s it.

You Can Make Decisions That Robots Can’t

If you’ve seen the "The Terminator" movie, you probably have a mental image of a not-too-distant future where machines can think like humans and therefore make decisions based on adaptive thought processes, such as being able to intelligently and emotively know what makes sense.

But unlike that film, the levels of which such tools can understand context and meaning (beyond what’s physically there) simply doesn’t exist today—though that’s probably a good thing as we don’t want the W3C validator going on a rampaging killing spree against <blink> tag users, right?

There may be a time where machines are as smart as humans, but that’s not today.

Code Validation

The most notable form of code validation in use today is that of the W3C HTML and CSS validators.

The level of obedience from some designers and developers to ensure their code validates is best reflected in the way many websites actually proclaim (through the use of badges) to the end user that their code is perfect (possibly to the point of sterility).

Proclaiming the validity of your code doesn’t mean what you’ve produced is perfect.

This reminds me of the way software developers proclaim awards from download sites as justification to use their product. As I’ve mentioned previously, however, the W3C validator (despite its association) is not perfect.

Failing Because of Future Standards

It’s an established fact that the W3C validator not only examines the structure of your site but the elements or properties themselves (though they don’t understand semantic value!).

The key issue with such due diligence from these tools is that elements which are not recognised (such as those of upcoming standards like CSS3 or equally valid proprietary extensions) are often misinterpreted by developers as "unusable" or "not approved" and therefore get rejected.

Taking Stuff Out For The Sake of a Badge

It seems rather amusing to me that people are willing to omit the value of somewhat acceptable but non-standard code — CSS3 attributes specific to particular browsers, for example — to satisfy the validators, like they’re trying not to anger the Tiki gods.

What ends up happening is the validators themselves make it seem like legitimate practices which defies convention are automatically wrong, and this results in a strange psychological condition in which people too quickly limit their own actions for the sake of a machine (or the ideology it provides).

While it makes sense not to use deprecated/future-standards code, validators simply can only test against what they know.

Nothing says: "I want approval" like these well-known badges of honour from the W3C.

It should be made quite clear that people who proclaim HTML and CSS validation on the page are doing so to make themselves feel better. Unfortunately, none of your users (unless you cater specifically and strictly to web designers and developers) are likely to know what HTML even is, let alone understand or trust what the fancy validator badge is telling them!

Web Accessibility Validation

If you want a case where validators totally miss the point and where their limited testing ability is abused (to proclaim the work which is being tested against is complete), you need look no further than the accessibility validation services like Cynthia, the now debunked "Bobby" and their kin.

One key issue with validators are that they can only test against what they can see (in almost all cases this only accounts for source code).

While some of the issues in WCAG can be resolved with some helpful coding (like alt attributes on images), code doesn’t account for everything in accessibility.

Cynthia "says" your site meets WCAG guidelines, but it’s often missing several points!

The Only Way to Test for Accessibility and Usability is through People

Accessibility and usability are highly subjective issues that affect many people in many different ways, and often the way code is presented (or even the content) does not establish where key problems may lie.

Too often beginners actively use the checklist nature of these services to claim their work is accessible on the basis that a validator covered what it could (omitting the complexities which it cannot account for – such as the sensory criteria and their inhibiting factors). This key lack of understanding and the wish for a quick fix showcases that reliance of these tools isn’t ideal.

How many validators can tell you how easy to read your content is? How many of them run a screen reader over the top of your site to denote the way a blind user may find your information?

While some factors can be mechanically replicated, the problem is the tools primarily focus on code alone and therefore miss the bigger picture (and those who rely on them also get caught up in this lack of awareness).

Without the background knowledge of how such web or software applications function, a scary number of people simply use them as an alternative to properly learning what they’re doing.

Do you speak Latin? No? This content would pass as accessible, readable and valid!

The state of accessibility tools is so bad that I advise people not to use them in favour of proper human checking.

The myth that tools can do things at an equal skill level of a human is far from the truth and while the W3C validators can be helpful, accessibility tools are too biased to be credited.

Translation Troubles

Confusion (as denoted above) in relation to such validation tools comes in many forms. Whether it’s the mystical messages the W3C validator produces (which beginners may not understand), the lack of fair warning that these tools should be used "as part of a balanced diet", or that these tools are often much more limited in what they can offer than you would be led to believe.

One of the more comical examples of automated tools going crazy can be seen through translation tools such as those provided by Babel fish or Google, which again proves that nothing is better than humans.

Google Translate is popular amongst websites for giving "rough" language translations.

One of the key elements of human languages is that words can have more than one meaning (and deciding which instance is in use can be tricky for machines – a case of context).

In accessibility, the issues of vision can be anything from total loss of eyesight right down to a case of color blindness. Because of this, a language translator will simply go for a literal meaning of the word rather than the context in which it’s used which can reduce your content into a scrambled illegible mess which doesn’t help your visitors (especially if they have learning difficulties).

While of course translation tools aren’t code validators, they do in fact perform a similar service. By taking a known list of criteria (whether code, words or something else), they attempt to check that something accurately portrays what it’s intended to.

If, however, you use something it doesn’t expect (like a new word in translation tools or a new property in the W3C validator), it will report it as a failing on your behalf.

Such reliance on validation tools for "perfect" results is therefore unjustified and can limit yourself to the detriment of your audience.

A Translation Exercise to Test the Idea

If you take a block of content from a website, paste it into Google Translate, translate it to another language, and then translate it back into English, you’ll see for yourself how badly these validators of content conversion are at the job. It can give you hours (if you’re really that much of a geek) of comedy in a few sessions!

See how the same sentence has been wrongly translated? It’s not uncommon!

The Silver Bullet

Knowing that validation tools are far from perfect is an important lesson to learn. Many people assume that such tools are an all-knowing oracle that accounts for everything your users or browsers may suffer.

While it’s wrong to say that these tools aren’t useful, it’s important to understand that the validation tools should not be used as a guarantee of accuracy, conformance or accessibility (in your visitor’s best interests).

A valid site should never be achieved if it sacrifices the progression of web standards, unjustly acts as a badge of honour or attempts to justify the end of the build process.

Knowing how and when to use code and the difference between right and wrong is a tough process we all undergo during our education.

The truth about validators is that sometimes being invalid is the right thing to do, and there are many occasions where a "valid" website is nowhere near as valid as you might like to think it is in terms of code semantics, accessibility or the user experience.

I hope that all of this will serve as a wakeup call to the generation of coders who either ignore or abuse validation services. These tools are not a silver bullet or a substitute for being human!

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

27 Comments

Jordan Walker

June 7th, 2010

Really a great article, it would be nice if the w3c would get on board with the browsers to create a specific set of validation rules.

Lauren Egan

June 7th, 2010

So true, as with anything in life, moderation is the key.

I definitely do not view validators as an end-all-be-all solution to coding. However, they are quite useful in catching an unclosed tag or if you’ve forgotten to turn an ampersand into a HTML entity – which is helpful when you do not have a second pair of eyes.

Good article – a topic not often written about.

Divyang

June 7th, 2010

That’s in-depth analysis of validation for website. Do search engines penalize for non-validated code?

Zlatan Halilovic

June 7th, 2010

Thank you Alexander for this truly awesome article :)

Wendy S.

June 7th, 2010

Thank you Alexander for this wonderful article. I’m just beginning to design and have had so many hair-pulling episodes because my css/html wasn’t correct according to the top “authority”. I can breathe a little easier now while still being disciplined enough to do my homework.

Dave

June 7th, 2010

Mr. Dawson’s translation example is rather weak: The two English sentences are largely equivalent in meaning. That they are not worded identically does not prove his point as conclusively as he seems to believe. (The Spanish translation is also close enough to the English to be equivalent in meaning.)

If Mr. Dawson were to give the outline of a thought to two people and ask them to write a sentence based on that idea, he’d be hard-pressed to obtain two identical sentences even if the underlying idea were the same. Difference in wording is not a difference in meaning.

Nevertheless, his overarching theme urging caution when validating still stands.

For my part, when I validate, I am attempting to write “correct” code for the same reason I try to write “correct” English: Part of the fun of writing–code or prose–is attempting to express myself within the rules of the language, however arbitrary or archaic they may be.

Like Neo in the Matrix, I can bend or break the rules of language or HTML–but only now that I’ve internalized them.

Perhaps validation is a crutch for beginner designers, but at the same time it helps them learn the rules of the language and provides immediate feedback on their use of the language (even if the feedback is limited to enumerating their errors).

And perhaps validation should serve as a warning to those of us who are more experienced: If we find ourselves consistently breaking convention to express ourselves, perhaps the language isn’t the problem.

Alexander Dawson

June 7th, 2010

@Divyang: It’s unlikely you will be penalised, however it’s worth taking the time to make sure it’s written to the best of your knowledge. Poorly written code may not best reflect the content semantics (and your rank could be affected) and (poor) style applied to poor markup may affect the end user. Neither are good idea!

@Dave: You’re correct that people do put things across differently, but I regularly read about individuals using Google translate as a replacement for professional translation. The example given is perhaps not the strongest, but it does highlight the imperfections that these tools can encounter (in a way most people can understand).

As I mentioned in the article, under-dependence (not using them at all) can be just as bad for beginners as those who go over the top. I agree they are fantastic tools and recommend people use them, but only for what they are… aids and helpful learning tools, not solutions.

Steve

June 7th, 2010

Awesome article.

I use the W3C validator as a reminder for the most part, developing strict XHTML it’s handy to know when you’ve missed an alt attribute, or you didn’t notice an ending tag, useful service – But it’s not the be-all and end-all of developing code.

Nathan B

June 7th, 2010

Trying to get your website to validate can be like trying to get every blade of grass to stand upright after you mow your lawn. The point is to have a healthy lawn, not a perfect one.

Pixelera Web Design

June 7th, 2010

From what I understand, Google also likes clean coded Websites, so another reason to learn W3C standards.

Jamie

June 7th, 2010

validators aren’t a crutch, they are a measuring stick by which you determine how close your code is to the specification.

If you’re using browser specific code (-moz, -webkit, etc), that isn’t _wrong_ per se, but users need to be aware that these items are not a part of the spec and may result in unusual behavior in some browsers.

There are other cases where the validator will throw an error (the start attribute on list items) but it doesn’t make it _wrong_ to do that either. With the list item attribute prior, it has been re-incorporated into HTML5 and coders can justify its use, just as long as they are aware that it may cause errant behavior.

Using validators is not a crutch.

Strictly adhering to valid code isn’t wrong.

Ignroing a freely available tool that is meant to help you create functional, cross-compatible websites is just foolish.

Nick Parsons

June 7th, 2010

Excellent article, Alexander! You have a very good point, and I completely agree. Validation and web standards should be used as the tool/set of guidelines that they are, but not treated like the god of the internet.

I believe that it’s acceptable to have code that doesn’t validate completely, as long as you have a good reason for it (like you’re using proprietary extensions to provide an enhanced user experience). Great post!

Alexander Dawson

June 7th, 2010

@Jamie: You seem to have missed the point. Any tool or aid can become a crutch if it’s abused or relied upon with no justification or knowledge behind it. No-one has said you shouldn’t use code validators, the point of this article is to highlight the issues that may occur as a result of either ignoring them or claiming the tools are a guarantee of excellence.

Jacob Gube

June 7th, 2010

Great comments everyone, and lovely discussion. I just wanted to write a comment about you featuring my web design for Design Instruct and not Six Revisions (the one that has a caption of “What does this design say to a machine? Nothing! It only sees the code and that’s it.”). I get the subtle hint: and I sound like a broken record, but I’ve been working on the re-design of Six Revisions for a while, it’s harder to re-design than design from scratch! :)

Great piece Alexander, I personally enjoyed reading it!

Lauri Kieksi

June 8th, 2010

While I appreciate the thought that usability, functionality and a workable design across browsers are of higher importance than valid code, this article feels like it’s going to unnecessary lengths to portray validation as some kind of compromise between valid code and functionality. You rarely have to make the choice of breaking your design and actually supporting standard markup. Unless of course graceful degradation for old browsers counts as “hacks” in your book.

Cristian Eslava

June 8th, 2010

Completely agreed. Robots translations are no good, they may give you more traffic but in the end you are giving poor content and content is and should be the main subject.

Best regards–

As you may notice I didn´t use a translator service that´s why my English sounds bad but not like a robot…

Renato Alves

June 8th, 2010

Man…

“The truth about validators is that sometimes being invalid is the right thing to do.”

P.E.R.F.E.C.T.
This article changed my mind about validators.

Things like XHTML/CSS validators and SEO rules induces many webdesigners limit their development power in detriment to these services. I think its not the right way.

(sorry for my english, i mean, the Google english LOL)

Ant

June 8th, 2010

Irony is that all sites that have validator badges I’ve seen, none of them validated. And most of them have bad code in addition.

spencer sy

June 8th, 2010

Great and helpful article Alexander. There are varied opinions about the validator as to whether it should be the “measuring stick” for the web industry. Some commented the Markup Validation is too “rigid” or “too automated”. Like in the CSS, I don’t put the unit “pixel” for margins and paddings which is a common, acceptable practice by coders and developers. But the validator sees this as invalid. Prominent websites like Google, Yahoo, Amazon are filled with hundreds of errors when validated but people don’t mind and they still command the most number of visitors. Bottom line is their business is working well.

Hoping one day we would have a modification that would be good for the industry.

David Siecker

June 8th, 2010

It’s important to note that website validation services and software recognize about 80% of the problems and help make the editing process go faster than the old days.

JJ Nold

June 8th, 2010

If one pays close attention to the code and validates early and often, then I think it’s perfectly feasible to write a website that validates while still keeping functionality.
CSS3 and HTML5 are completely different stories.

Joost

June 8th, 2010

I use some of these validators (and jsonlint) as tools to errorcheck my code. Just to see where and if I made a mistake, if I missed something.
They can be a good teaching tool for beginners as well.

But, as long as you know why and have a good reason for choosing not to adhere to a standard there should no problem.

Saying that, writing html that passes the w3c validator is easy and in general good practice. I rarely see a good reason to break the recommendations.

But that is just one small part of writing decent markup.

ejaz14357

June 13th, 2010

But, as long as you know why and have a good reason for choosing not to adhere to a standard there should no problem.

M.akrmsaim12812

June 21st, 2010

It’s important to note that website validation services and software recognize about 80% of the problems and help make the editing process go faster than the old days.

J.S. Ferguson

June 27th, 2010

Great article.

The validators that I’ve written, WebLight and Tart, have always allowed people to categorize and filter messages so they can ignore messages related to conscious choices they’ve made and find unexpected problems more easily.