Goal
Ensure that the technology that reads our web markup can parse it and confirm that it’s valid.
Why this matters
If the code is invalid, it’s likely to produce unexpected results. For example, the web archive for a page on the Sewing and Embroidery Warehouse site shows that if you don’t close your header tags, they can multiply in size instead of displaying at the intended size.
A little closer to home, I’ve seen paragraph tags embedded in paragraph tags (no), links inside of link (also no), tags closed out-of-order (nope) and any number of any other “whoops” scenarios cause both semantic and visual defects for users.
We validate our markup for the same reason that we run spellcheckers and ensure our code compiles before pushing it to production: if we can catch mistakes before they happen, they’re cheaper, faster, and much less embarrassing to fix.
How to implement
- If you’ve got an HTML file on a public server (rare), the benchmark is the W3C Markup Validation Service.
- If you prefer to (or must) validate using a browser plugin that will check the page you’re currently viewing, validators are available for all major browsers. Links to a few validators are as follows:
- Firefox – HTML Validator
- Chrome – a list of HTML extensions are available
- Safari – Textlab
- Microsoft Edge – Total Validator
How to test
Once you have the validator of your choice, run it against the markup and determine what is and isn’t validating correctly. Then, either correct the issues or find someone in your organization that should correct the issues. (It’s always polite to contact them first to prevent opening duplicate issues.)