This is another one of the “Do’s” on the list of Do’s and Don’ts that all web developers should employ as part of their web development process. And I know there is a crowd of dissenters who reject the notion that their code or web documents need to be verified, poked, prodded, tested, and validated before going live to public viewing.

Several of the opponents to validating code argue that there is no guarantee that a web document missing the correct syntax will not display as expected; their thinking is that if the page does what we want and the user experience is a positive one, why care about quality assurance, standards, technical specifications, and guidelines? Another point made for defying validation includes the time needed to conduct the processing for all the code, especially with development involving large numbers of web documents that could take up a lot of resources, time, and effort. Yet another point in the revolt against validation is that the average visitor does not look at the source code, so if the page looks good in the browser, then they are happy.

All I can tell the rebel web slayers out there is that validation is considered a best practice, and best practices are just what they mean, the best way of doing things — not always the right way for everyone or every organization, but typically it is the best way of managing and controlling code development.

Let’s face it; no one likes to be told that their code is invalid; for that reason, I’m providing several quick tips here that will help you with getting over the perceived stigma, and send you on your way to honorable code.

Validation ensures that your code will be rendered in the best possible way for all known user agents whether it is written in HTML, XHTML, SMIL, MathML, etc. The online W3C Validation Service W3C validation provides several options. The most popular is to validate by URL scan, just copy in the address, click “check,” and voila — your scan report is generated in seconds. Other options include the ability to scan specific content such as RSS/Atom feeds, CSS stylesheets, MobileOK content, or to find broken links. And there are other valuators and tools available. You may have your own validation application, and that is fine too; these tips can be used in either situation.

Tips and tricks to streamlining your validation process:

  1. Upon running a validation test scan, your code may return several warnings and errors. Note that the errors have more priority over the warnings.
  2. Consequently, you will want to address the errors first in an orderly fashion concentrating on one error at a time. The validation errors and warning list will be presented in descending order, the same order that it appears in the code from line 1 on down to the end of the code.
  3. Knock out each error individually, and then run your validation test again to ensure you tackled every single one.
  4. Then concentrate on the warnings: What you might find is that when you correct one error or warning it may resolve several others. So it is good to run the validation several times as you address the issues, especially if the code generated a lot of errors and warnings.
  5. If you have time constraints to validating your web documents, start with templates first, then create a system for validating code after major design changes are dealt with. I like the saying “You can only eat an elephant one fork full at a time.” Therefore, if your web document directories and folders are the size of an elephant, break it into manageable sections. Set aside one hour a day or several hours a week to conduct validation.

Besides the online W3C Validation Service, there are others out there available for free, both online or downloadable applications and I have listed a few of them below:

HTMLTidy: Dave Raggett’s excellent HTML Tidy application download lives at SourceForge, where they collect all the bugs and patches and have refactored Tidy into a free-standing C library.

Tidy Your HTML: The online “Tidy” tool.

Web Page Purifier: Enter the URL, select the HTML purity level, then run the view page to validate; you can also view the CGI Perl source code.

Web Page Backward Compatibility Viewer: Allows you to check off any features that you would like to include or exclude from the scan. This tool also allows you to enter the browser ID string; the results of the scan can be viewed in CGI Perl source code.

A-Prompt Web Accessibility Verifier: This downloadable application checks for web pages’ accessibility-readiness for people with disabilities; it actually performs repairs on code with queued response. The tool examines web pages for any barriers to readability and access for people who are blind and who rely on screen readers to synthesize speech from the computer.

IDI Web Accessibility Checker: Another tool that checks single HTML pages for conformance with accessibility standards to ensure the content can be accessed by everyone.

Do you have any other tips, tricks, or resources for code validation that you use in your practice?