Beyond Validation

January 15, 2007

Topics: Accessibility, Web Development, Web standards.

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.

15 Comments on “Beyond Validation”

  1. I gave up coding because of this validation thing. I seems to stuck in a hole finding the answers to my wrong-coding. 🙂

  2. Although I don’t personally support the use of tables for layout, the actual impact of using them is a fairly complex answer. In general, it’s not whether or not you’re using tables; it’s how you’ve applied them in the specific layout. They can cause problems, but it’s not a problem which is inherent in the fact of using a table.

    I wrote on this pretty extensively in Tables or CSS (Cascading Style Sheets) Layout?. Read that article for a more elaborate examination.

  3. Great Article, this reminds me that I have to get my code verified as well. I’m embarrassed but yeah I made my blog’s layout on tables but my question is that if I fix all other errors, does it still really make a big difference?

  4. Interesting article with good points


  5. A List Apart released an article that talks about the power of validation etc

  6. Ah, comments…no, I didn’t get around to that…

    Another time! 🙂

  7. Yeah Its not easy but it is a good learning curve especially for clients and customers in the future. because if you can ‘sell’ these practices to people stuck in their old ways, you will be able to do it to customers and clients who do not have a clue.

    BTW thanks for reading my posts (didn’t see any comments though 😛 )

  8. It looks like you’re in a bit of an awkward situation, Jermayn! (I read a few of your other posts, as well.) It can be difficult being in a place where you, as the junior developer, are trying to implement modern, standards-based ideas when all the senior developers are stuck in the late 1990’s. My advice: deal with it and move on. The experience will be valuable to you regardless of whether you’re able to guide the project on the best possible path.

    As to your article, you’re right – specific doctypes make a huge difference. That’s one of the key points to this article, itself. Thanks!

  9. I have also like Aiden just posted a similar post about validation, titled “Different Doctypes and Do They Matter for Standards?

    Reason I posted about it is because I am in the middle of placing content in a new government designed website that uses a transitional doctype and has been sold by the original creators as AAA accessible.

  10. Well, that’s interesting, Aiden. Unfortunately, you do seem to have missed my point entirely. I didn’t claim in any way that validation wasn’t important, as you’re saying in your article. I stated that validation isn’t the most critical, most valuable part of website development you can focus on.

    I’ve never said in any way that a page shouldn’t make a point to validate – it simply shouldn’t interpret that validation as any kind of indicator that they’ve accomplished the job of creating a high-quality web page.

  11. I just wrote up a post about validation myself, along with a look at the Top 50 on Alexa and their results on validation. Take a peek, it’s pretty interesting.

    Validation, What Is It Good For?

  12. For what it’s worth, at the time you read this article, James, I was currently in the process of making some design and codebase changes to my site.

    Believe it or not, over 1460px wide wasn’t the first scale I tested. I appreciate being told about the problem.

  13. Interesting article with good points, but written my someone whos page breaks at around 1460px wide!

  14. Exactly the point I was trying to make…although perhaps a bit more concise! 🙂


  15. Very well put.

    Validation is just one of the pieces that make up an accessible and well-constructed web page. It’s an important one, but it’s very easy to create tag soup rubbish that validates. Layout tables validate. [img src=”big-red-bullet.jpg” alt=”big-red-bullet.jpg”] validates. [font face=verdana size=1 color=silver] validates (against Transitional, anyway).

    But unless your site validates, there’s a very strong chance that it will be inaccessible or that it will break. Especially if you’re claiming it to be XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language))!