Valid HTML is not a working page

The comfortable green checkmark

Run a page through the W3C validator, get no errors, and it is tempting to conclude the page is done. The conclusion does not follow. Validation answers one narrow question: does this markup conform to the HTML specification's syntax rules? Working pages and valid pages overlap, but neither contains the other.

This distinction matters more now than it used to, because generated markup tends to validate. Modern tools rarely emit unclosed tags or illegal nesting. The failures that remain are the ones no validator is built to see.

What validation actually checks

The validator parses your document the way a browser does and reports where the markup breaks the specification: elements that cannot contain other elements, attributes that do not exist, duplicate identifiers, a missing document type. These are real defects and fixing them is cheap. Parsing errors can silently reshape your document, and a duplicate id can break label associations and fragment links in ways that are miserable to debug later.

Validation is the right first gate precisely because it is mechanical. It never has an off day, and it costs nothing to run.

What validation cannot see

Every one of the following passes validation without a warning:

• An image whose alt text reads image123.jpg. The attribute exists; the content is useless.
• A page whose headings are chosen for their font size, producing an outline that reads as nonsense to anyone navigating by structure.
• A form whose visible label sits next to the input without being associated with it, so assistive technology announces nothing.
• A click handler on a generic container, producing a control that keyboard users cannot reach and screen readers cannot name.
• Text at a contrast ratio no one with low vision can read.
• A focus order that jumps across the page because the visual layout and the document order disagree.

None of these are syntax. All of them are failures. WCAG exists because conformance to the markup grammar was never the bar; the guidelines describe requirements a validator has no way to evaluate, like whether a name is meaningful or an order is logical.

The evidence that the gap is real

WebAIM's annual survey of one million popular home pages finds detectable WCAG failures on the overwhelming majority of them, year after year. Two things make that number worse than it looks: automated detection only covers the subset of accessibility requirements a machine can evaluate, and a clean syntax check would not disprove any of the detected failures. The real failure rate sits above what any scanner reports.

Why generated pages concentrate the problem

A model asked for a landing page optimizes for what the requester will inspect, and requesters inspect rendered output. Legal syntax comes free with the training data. Meaningful accessible names, sensible focus order, and honest heading structure do not, because nothing in the request demanded them and nothing in a screenshot reveals them. The result is a generation of pages that pass the validator on the first try and fail the first keyboard user who arrives.

Reading validator output like a reviewer

Not every message the validator prints deserves the same reaction, and treating them all as equally urgent is how people burn out on the tool and stop running it. A few are structural and worth fixing immediately whenever they appear. Duplicate id values are the standout: identifiers are the connective tissue between labels and inputs, between fragment links and their targets, and between ARIA attributes and the elements they reference, so one duplicate can quietly break three different mechanisms at once. Misnested elements are the other priority, because the parser recovers from them by rebuilding your document into a shape you did not write, and every later check runs against that rebuilt shape rather than your intention.

At the other end sit messages that are technically accurate and practically minor: informational notes about trailing slashes on void elements, or warnings about sections lacking headings in places where no heading belongs. Fix them when convenient, but do not let them crowd out the structural failures. The skill is triage, and it is the same skill every other audit in this article requires.

There is also a category the validator stays silent about that people assume it covers: broken links, missing images, and misspelled attribute values. An href pointing at a page that does not exist is perfectly valid markup. Validation checks the grammar of the document you wrote, not whether the things it points at are real. That verification belongs to the deployed-response checks at the end of the audit, which is one more reason the validator cannot be the last gate.

The audit that catches what the validator misses

Order matters. Each layer catches what the previous one cannot:

1. Validate to clear the mechanical defects.
2. Scan with an automated accessibility tool to catch the machine-checkable subset: missing alt attributes, contrast, unlabeled fields.
3. Tab through the page from the top. Every interactive element reachable, focus visible, order sensible, no traps.
4. Read the accessibility tree in developer tools and confirm each control has the role and name you intended.
5. Check the deployed response, not the local file: status codes, canonical, headers, and the form actually submitting.

The free audit prompts on this site structure steps two through five for pages you did not write yourself.

The honest summary

A validator proves your markup is legal. It cannot prove your page works, any more than a spell checker proves a sentence is true. Treat the green checkmark as the start of review, and the pages you ship will earn the trust the checkmark only implies.

Frequently asked questions

Does valid HTML mean my page is accessible?

No. Validation checks syntax against the HTML specification. It cannot judge whether alt text is meaningful, focus order makes sense, or a control has an accessible name. A page can validate perfectly and be unusable without a mouse.

Should I still run a validator?

Yes. Validation catches parsing errors, unclosed elements, and illegal nesting cheaply and reliably. It is the right first check. It is only wrong as the last check.

What should I run after the validator?

An automated accessibility scan, a keyboard-only pass, a reading of the accessibility tree in browser developer tools, and the same checks against the deployed URL rather than the local file.