Specifically the idea of them building client side code which complies with standards such as XHTML 1.0 Transitional, CSS 2 (probably the two most commonly followed ones at the moment) and, dare I suggest, WCAG 1.0 (Accessibility).

Whereas most good books (such as Bulletproof Web Design and so on) not only recommend that standards are followed but also give lots of tips on how to do it, most developers I’ve ever worked with see standards compliance as another overhead, in the same bucket as doing their timesheets and attending team meetings. The code would work just fine without them, no one will notice if they didn’t do it and what value does it really add. Etc.

I can see why they might think this way.

There are loads of examples of high profile, hugely popular commercial sites that are clearly not standards compliant – even at the technical code level, as any simple check using the W3C Validator will show. It doesn’t appear to have harmed their search engine rankings or affected their ability to display correctly in various browsers. (Though the additional costs of making such “non-standard” compliant sites achieve this must be enormous.)

And almost all of them gets away with it. Though now and then, some site owners are prosecuted the cases are sadly few. Naturally, this therefore strengthens the case for the non-standards compliance school. If the big guys don’t comply and they don’t suffer as a result, why should anyone else bother.

Yet standards compliance is so simple to achieve and really doesn’t take much more time to do, so it shouldn’t be seen as such a burden. It basically amounts to producing clean, tidy and efficient code and using html properly – ie. semantically – which is what any good developer should surely be striving to do. I often use the analogy of a journalist complaining if they are asked to spellcheck their stories – surely it should be something that they do as a matter of course in the quest for quality.

Accessibility is a little different. Accessibility does require going that extra bit further, tagging up titles, using tabs and hot-keys to aid navigation, providing non-javascript versions of key content if you’ve also used javascript for it and so on. Being standards compliant takes you a long way to having an accessible site, but not completely.

But even then, it really doesn’t take too much more effort. And there are loads of tools to help check for compliance. I discovered a very good one recently – Total Validator. You can use it to check your code against the various html standards at the same time as you test for code-based (as opposed to content-based) accessibility compliance.

At the end of the day, whether its a legal requirement or not, it makes good sense to produce neat, clean standards-compliant code. It loads faster, works across more devices, is easier to maintain and ultimately better for users.

There’s really no excuse not to do it.

I always ensure I validate my site against XHTML 1.0 Transitional and typically it has been the plug-ins from YouTube, Google and now SpringWidgets that have needed some fixing.

Anyway, a while back I discovered an article on A List Apart, talking about the Flash Satay method of fixing Flash code and explaining the changes needed. It is quite detailed but it really boils down to two things.

Ampersands and embed tags. Get rid of them.

Simply replace “&” symbols with “&” and delete any “embed” tags within object tags.

You might need to do a bit more for certain plug-ins but I’ve found that making those two simple changes fixed the plug-ins for YouTube and SpringWidgets.

Nice and easy!