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!).

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.”

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…

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.

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.

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.

– 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!