For any qualified web developer, code validation is a step. Usually a step which is repeated frequently through the development process – and an important step, certainly, but just one small step in the process to create a standards-based, accessible web design.

Validation, by itself, should never be considered as a primary signifier concerning the quality or accessibility of a website: not all validations are equal, after all. There are a number of important questions to be asked when looking at validation reports – and then there are the vast steps to be taken beyond the validation process. A passed validation demonstrates care and carefulness in the construction of a website – but that validation must be looked at carefully, and you need to also remember that a failed validation does not necessarily indicate the opposite.

What is this page validating against?

There are a number of possible DTD (Document Type Definition)’s which a page can be checked against:

  • XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) 1.0 Strict, Transitional, or Frameset
  • HTML (HyperText Markup Language) 4.01 Strict, Transitional, or Frameset
  • XHTML 1.1
  • HTML 2.0
  • HTML 3.2

And, for specialized uses, there are SVG (Scalable Vector Graphics), MathML and combined profiles. But I’ll ignore those for my purposes right now…

Is a page which validates perfectly using the HTML 2.0 doctype superior to a page which fails to validate to XHTML 1.0 Strict? Maybe…but then again, perhaps not. The validation alone cannot tell you: XHTML 1.0 Strict still allows you to use tables for layout. The validator can’t distinguish between a table used for data and a table for layout – this requires human judgement.

Any transitional doctype should immediately raise eyebrows. Arguably, one reason the transitional doctype exists is to provide a valid path towards strict HTML and XHTML. A valid transitional doctype will allow numerous tag usages and attributes which are excluded in equivalent strict doctypes. The W3C (World Wide Web Consortium) validator allows you to evaluate a document against any DTD you choose: use this. Check that transitional doctype page against the equivalent strict DTD and see what happens. Sometimes, the page will pass or come very close: other pages might spawn tremendous numbers of errors.

What errors have been made?

The mistakes displayed on validation can tell you a lot about the site: the biggest thing to take note of, however, is the severity of the error. At some levels, it’s obvious. A page with 400 errors clearly has not taken the effort to validate in any way. An XHTML 1.0 Strict page which produces numerous errors involving unclosed tags and invalid nestings is probably caused by somebody who switched from HTML 4.01 to XHTML without being aware of the differences in the two languages.

The number of errors alone is not a perfect judgement: a single missing final </div> or </p> can spawn dozens or hundreds of errors, depending on the position of the error and the complexity of the page. These errors are minor: difficult to find, difficult to see, but easy to correct once they’re located.

The main point of this argument is to realize that the simple fact of validating or not validating and a static number of errors does not demonstrate anything significant about the page. Take a closer look: learn the principles of each DTD and see what a difference it makes.

Beyond Validation

Completely outside the narrow boundaries of code validation there are issues of accessibility and usable design which can’t be judged by machine code. Quoting myself from a Cre8asite posting:

Think of [validation] as a sanity check – just verifying that everything you’ve written accords with the language logic. It’s easy to write some pretty bad code which still validates – using tables for layout, for example, is a poor practice, but you can certainly still make it validate.

Beyond validation there’s a whole world of thought in considering image sizes, color contrasts, typography, navigation methods and semantics which can be the greatest aid to a user or user agent.

Does validation tell you whether your images have alt attributes which convey appropriately what this image is, what it says, or are blank if that image serves no purpose? Does validation tell you whether your color choices provide a sufficient contrast for users with low vision? Does validation inform you that your navigation can be used by a screen reader or followed by a search engine spider? Frankly, no. Validating your CSS (Cascading Style Sheets) can give you a hint – you’ll be warned if you’ve declared the same color for both background and foreground, but it’s just a warning – and only if you’ve used the same color. Nothing about contrast.

Your eye and your brain are some of the best tools you have. Applying those tools effectively will take you a long way towards accessibility.