QUICK ANSWER
What you should remember
- Validation is a sequence: parsing, semantics, accessibility, behavior and real-browser testing.
- A browser rendering the page does not mean the source conforms to the HTML standard.
- Fix errors closest to the top first because one malformed token can create several later reports.
- Automated checks support human review; they do not replace keyboard and screen-reader testing.
Validation is more than “does it render?”
Browsers recover from many mistakes, which is helpful for visitors but can hide fragile source code.
Conformance checking asks whether a document follows the HTML rules. Quality review asks whether the chosen elements communicate the right meaning. Accessibility review asks whether people can operate and understand the interface in different ways. Functional testing confirms the page actually completes its job.
AI-generated pages need all four because a model can produce syntactically plausible markup with duplicate IDs, unlabeled fields, fake links, invalid nesting or controls that look interactive but are not.
Run validation in four passes
Separate the checks so each report has a clear purpose.
- Pass 1: parse and conform
Check doctype, nesting, attributes, IDs and element placement. Resolve the earliest errors first and rerun the report.
- Pass 2: inspect meaning
Use headings in order, landmarks for page regions, buttons for actions and links for navigation.
- Pass 3: test accessibility
Use the keyboard, enlarge text, verify labels and alternatives, then test important flows with assistive technology.
- Pass 4: exercise behavior
Submit forms with valid and invalid values, activate every control and watch the console for runtime or resource failures.
Example: valid-looking form, missing meaning
Placeholder text is not a dependable label, and a clickable div is not a native button.
<input placeholder="Email">
<div class="submit" onclick="send()">Submit</div><form id="signup">
<label for="email">Email address</label>
<input id="email" name="email" type="email"
autocomplete="email" required>
<button type="submit">Join the list</button>
</form>The reviewed version gives the field a persistent accessible name, uses built-in email validation and exposes a real button to keyboards and assistive technology. The form still needs a controlled submission handler, useful error messages and a privacy explanation.
How to triage a long error report
Do not attempt to fix forty messages at once. Many may share one upstream cause.
- Save a snapshot, then fix the first error and run the checker again.
- Group duplicate-ID and missing-label warnings by component so templates are corrected once.
- Treat an unfamiliar attribute as a research task rather than deleting it automatically.
- Recheck the visual result after structural changes because browser error recovery may previously have shaped the layout.
- Record intentional exceptions so a later maintainer understands the decision.
A practical definition of done
A page is ready when its important journeys are understood and repeatable, not merely when a tool reports zero errors.
| Area | Evidence | Minimum result |
|---|---|---|
| Markup | Saved validator report | No unexplained errors |
| Keyboard | Manual tab-order notes | Every action is reachable and focus is visible |
| Responsive | Phone, tablet and desktop checks | No lost content or horizontal page scroll |
| Forms | Valid, invalid and empty submissions | Clear labels, errors and confirmation |
| Resources | Console and request review | Only intended files and domains load |
| Change control | Diff from generated draft | Reviewer can explain important changes |
Use these tools with the workflow
Each link opens an existing HTMLOnline tool or course that supports a specific part of the review.
Standards and primary references
These references support the standards and product-capability statements in this guide. Our workflows and examples are original.
- Nu HTML CheckerW3C
- Conformance requirements for authorsWHATWG HTML Standard
- Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative
Frequently asked questions
Does valid HTML guarantee an accessible website?
No. Valid markup removes many structural problems, but accessibility also requires appropriate semantics, keyboard operation, understandable content, contrast and manual testing.
Why does my page work when the validator reports errors?
Browsers include error-recovery rules and often construct a usable document from malformed source. Different tools or future edits may expose the underlying problem.
Should AI fix every validation warning automatically?
No. Ask for an explanation, make a small reviewed change and rerun the checker. Some warnings need product or content decisions rather than mechanical rewriting.