Working together for standards The Web Standards Project

The debate over validation has raged for a long time, with heated arguments on both sides. In his article “Where Our Standards Went Wrong,” Ethan boils the debate down to two contrasting opinions:

1. You take a hardline stance, rightly stating that if we fail to follow the conventions of a language, then we’ve produced something altogether different and, well, invalid.
2. You take a pragmatic view, rightly stating that the invalid code generated by broken tools and third-party code shouldn’t negate one’s overall commitment to web standards.

He then asks So if both views are right, where does that leave us? and posits that we are at an impasse.

Further along in the article, Ethan discusses the ways we sell standards. He notes the sexier bullet points

• shorter development cycles,
• lower maintenance costs, and
• decreased page weight

but also laments the our failure to sell other benefits such as

• increased accessibility,
• device independence, and
• the ability to make your site future-proof.

Which brings him back to validation and how it can actually be used to sell standards.

Looking back on last year, Ethan noticed about 15% of his work time was spent working around invalid code. With that discovery, he came to the conclusion that [i]nvalid sites may look the same as those built on a foundation of valid, well-formed code, but in my experience, they invariably cost more to maintain. That may seem obvious to you, but he argues that it is not typically a feature we sell to our clients as part of that standards package.

When you are pitching a project to a client or discussing standards with them, which benefits do you highlight? Why?

Your Replies

#1 On March 1st, 2007 11:42 am Rick Curran replied:

I think the two points of failure that he mentions are very important selling points:

– increased accessibility
– the ability to make your site future-proof

I know many clients disregard these are not being of consequence, but it’s really down to a matter of taking time to try and help them understand the benefits. Future-proofing a site by making it easier to adapt to a new design further down the line should equal cost-saving in the longer term.

Accessibility is sometimes a hard sell to the ‘man on the street’ as it were but it’s increasingly an issue to present. It’s not just about accessibility for impaired users but accessibility of devices, certainly in the UK this is an area which is going to grow. This is where the ‘device independence’ aspect (which I consider part of accessibility) of coding towards standards is great due to not having to do 2 separate versions of a site. Yet again though persuading the man on the street that this is a benefit may be difficult.

Just a few thoughts!

#2 On March 1st, 2007 11:43 am Web Messenger » Another way to look at validation replied:

[...] Original post by unknown and software by Elliott Back [...]

#3 On March 1st, 2007 12:43 pm Robert replied:

It is not hard to write valid code. It is hard to make clients write valid code.

When you code your templates for the CMS, make them validate. If the client adds invalid code, there is really nothing you can be expected to do. If I sell someone a gun for hunting, and they rob a store with it, I can’t be expected to be there to stop them. If you are a resourceful back-end programmer, all client input can be run through HTML Tidy before adding it to the database. This will, at least, reduce the chance of your client knocking over that 711.

As I’ve said time and again, XHTML has it’s place. However, HTML is more forgiving. On a site that you ultimately have no control over user input, it is more likely that HTML pages will continue to validate. Using HTML instead of XHTML does not mean you aren’t using Web Standards. Apply the same stringent standards to your HTML code as you would your XHTML code, and let the client do what they will on the CMS.

If the page ends up not validating because of client input, it’s not something you, the designer, did. It isn’t your fault; your commitment to standards was fulfilled when the pristine site you uploaded was valid. Commercial web design isn’t at odds with validation. Client-generated content is at odds with validation. Using WYSIWYG client-input tools like XStandards in conjunction with HTML Tidy will make it easier. Some simple training on markup (or using some alternate markup, like Markdown) will help even more.

The only other alternative is to do updates yourself so that you can make sure the sites validate. However, I don’t think this is necessary. The situation just isn’t that dire. The tools we have can be made to work.

#4 On March 1st, 2007 1:27 pm Circle Six Blog » Blog Archive » Selling Standards replied:

[...] From: Another way to look at validation – The Web Standards Project [...]

#5 On March 1st, 2007 3:00 pm Peter replied:

There is nothing inherently wrong with having high ideals, but sometimes those ideals are unrealisable or at odds with “practical” web development.

Standards based development can promote the qualities of perfection, desirability, and excellence for the greater good of all parties.

As developers, we shouldn’t be afraid to aspire to facilitating fully valid xhtml by means of the tool that we have designated to be our CMS.

But the reality of practice is usually that of an (relatively) unskilled client cutting and pasting a word document into your valid xhtml template and not using the appropriate tools to structure the document prior to publishing it.

Web standards are becoming more visible outside the hermitage of developers blogs and excellent websites such as this.

Web publishing is changing, web standards are beginning to make a difference, as a community it is up to us turn what was once idealistic into a pragmatic reality.

#6 On March 4th, 2007 2:28 am Martin replied:

The pragmatic approach always sells because it is doable.

If we are to move to an idealistic view of ensuring web pages are written in 100% valid code, we need some helping hands from all corners such as web authoring tools, content management systems, etc.

We can easily put in 100% valid code, but the end result doesn’t mean it is always valid such as a client inadvertently made it invalid.

#7 On March 4th, 2007 11:03 am Philip Storry replied:

Any business ignoring accessibility is an idiotic business.

Around Christmas, I found myself in London near five o’clock. I’d spent a while shopping, and had a lot of bulky bags with me. I could either go home, or go to another shop. But I didn’t want to waste my time – after all, it was near five. Many shops might be closing soon.

So I fired up my phone’s web browser. I knew where I wanted to go, so I went to their website. And after having waited five minutes for it to download the mess of invalid HTML on their huge pages (drop-down comboboxes for navigation had about 40K of options!), I gave up.

I had been willing to grab a black cab for the mile and a bit, pop in, buy something expensive and then pop home. But only if I knew they were going to be open. As I couldn’t even navigate their nightmarish website to find out when they closed, I went home and got what I wanted elsewhere the next day, much nearer to my suburban home.

This city center retailer lost out on a sale simply because their website couldn’t get me to their address and either their phone number or opening times quickly and easily from any device. Their front page is almost half a meg large with all its images. The page itself is almost 90K. Fine on broadband, tolerable on dial-up, inexcusable on a mobile device using GPRS.

Bad design costs sales. Feel free to use this scenario with clients who insist they want to lose money, folks. It may help them focus their minds…

#8 On March 8th, 2007 4:08 pm Trails replied:

The benefit I always pitch is cost.

Unless the person is web-savvy (and even then, not always) or has some personal buy-in to accessibility (either they know someone who has disabilities, or have been taken to task for failing to meet accessibility guidelines), it’s too far removed from their experience for them to understand the benefits of an accessible site.

“Future-proofing” and “device independence” are just ways of saying “it’ll be cheaper to do X”. I definitely include both of those, but I relate it back to cost. E.g. “In phase 2, if you want to support PDA’s, all we have to do is build and apply alternative stylesheets. Otherwise, we’d have to blah blah blah and that’ll cost you a lot more.”

#9 On March 15th, 2007 5:17 am Autocrat replied:

A little off-topic, but includes these ideas…

If you want something to be known, to be respected and to be followed – enforce it.
Either use Positive or Negative re-enforcement techniques.

The reasons that issues such as Accessibility are not up and running as much as they should be are many, but I view the main ones as;

Lack of knowledge – User
Lack of knowledge – Client
Lack of Knowledge – Designer/Coder
Time/effort to re-learn (properly :) )

Stating that there is little help from software applications etc annoys me – if you cannot figure it mentally and in a plain text-editor, there are always going to be problems!!!

——————————————————————–

IF there truly was a standardised body that CHECKED whether sites where valid, and POLICED things – then maybe things would change.

IF search engines listed you as special because your site is Valid, Accessible and went out of it’s way to be “good code” – then it would make people pay attention.
Alternatively/additionally – Penalise those with shoddy code (but only those built recently!).

It’s harsh and a little unfair to some – but hell, in the uk, you cannot be a mechanic, boiler fitter, electrician or basicaly state your qualified to pass-wind unless you have a valid trading license!!!!

Our line of work needs the same.

Yet there isn’t one – there are no special rewards for the time and effort to learn, to make amends, to go back and finish.
There is no such thing as being licensed or qualified in this field of work…
(yep, I got a program, I built some graphics – I’M A WEB DESIGNER!).

#10 On March 23rd, 2007 5:18 pm Salmonized » Blog Archive » links for 2007-03-23 replied:

[...] Another way to look at validation – The Web Standards Project (tags: standard validering) [...]

Post a Reply

Comments are closed.