XHTML compliance – here’s why

The MossyBloggers are asking why the XHTML/CSS path is the way to go; not because they aren’t fans of the approach, but because they are having difficulty with the effort-payoff dichotomy. I understand why they’re asking, but perhaps I think they haven’t struck the issues we have at ITR.

Of course, being a web dev shop inside a federal government agency, all our clients are internal. That doesn’t mean our client base is small or non-demanding; we have upwards of 25 distinct sites we’re responsible for (whimper).

Recently, we had a very demanding client who wanted Flash-this, frames-that, popups-something else. Not interested in hearing about our standards-based approach, we finally had to pull out the 800 lb. gorilla; the LAW, in order to make this individual sit up and pay attention.

It’s a little-known fact that every web site developed in Australia must, by law, fulfil the requirements laid out in the Disability Discrimination Act (which you can read at your leisure here, and read the more friendly Advisory Notes here); a fact which is policed by the Human Rights and Equal Opportunity Commission.

It only takes one disgruntled user of your site to complain, and the Commissioner and his right to impose hefty fines will be down upon your head. Take the Sydney Olympics web site as an example, and check what Google offers up. Here’s a helpful summary.

Along with the legal requirements we face, the XHTML/CSS approach offers a wealth of benefits. Here’s my (hopefully) definitive list:

  • allows distinct separation of content and delivery, allowing reuse of content in multiple delivery platforms (web, print, phones, etc.), especially if the content is held dynamically (i.e. in a database)
  • allows easy visual redesign of websites when the content doesn’t require significant change (just take a look at CSS Zen Garden)
  • allows designers to more easily take into account usability and accessibility requirements (whether they’re US s.508, Australian Disability Discrimination Act or some other requirement
  • provides an accepted and known standards-based approach to your web site delivery (useful when your team gets hit by a bus and needs quick replacing – heaven forbid!)
  • covers your arse when people who want to complain about the accessibility of your site raise their voices – their complaints are effectively and rapidly silenced

I fully accept that the upfront effort is at times especially onerous, but I think the payoff is definitely worth it in the end. That’s my take, anyway. Responses welcome.

5 Replies to “XHTML compliance – here’s why”

  1. All the points you mention have nothing to do with ” why xhtml “.

    All your arguments can be accomplished with HTML 4.0 also :)

  2. Yes, what I suggest can quite easily be achieved with HTML 4. However, in seeking to maintain parity with up to date standards (which we have chosen to do), as well as keep the vast bulk of our content as XML in a database, we are significantly convenienced by using XHTML.
    Following this standard means that for our web development group, which can be as many as 20 people at times, their knowledge is kept up to date and standardised. We can bring new workers up to speed very quickly.
    Additionally, we (as stated) store absolutely no presentational information in our XHTML (at least for recent sites). Everything presentational is in CSS. This is of huge benefit when we have clients who want to retain their data, but drop a new look and feel onto their site. We can do this fairly quickly and painlessly using CSS.
    We store much of our data as XML, and then transform it to HTML prior to presentation in a browser. Doing this, we have a huge repository of corporate data that doesn’t need to be kept in multiple places and formats – we can use the same data we have for web for doing print work, thus saving on rehandling.

  3. >>we are significantly convenienced by using XHTML

    No, you could do exactly the same with html 4. Zero difference. Just close all tags, that’s all.

  4. Following this standard means that for our web development group, which can be as many as 20 people at times, their knowledge is kept up to date and standardized. We can bring new workers up to speed very quickly.

Leave a Reply