Article · Intermediate
Why semantic HTML matters when AI writes the first draft
Treat generated markup as a proposal, then review meaning, browser behavior, accessibility, and production evidence before publishing.
- Author
- Adam Wilkie
- Published
- Last checked
Generated code is a proposal
An assistant can produce a plausible page in seconds. That speed is useful, but the output is still a proposal. A visually convincing result can contain the wrong element, an invented claim, a broken keyboard path, or a form that has no real destination.
The safest workflow separates generation from acceptance. First define the page’s purpose, content hierarchy, real facts, and technical constraints. Then generate a small artifact. Review the rendered behavior and source before deciding that it belongs in production.
Meaning survives presentation
Semantic HTML records what content and controls are, not merely how they look. A heading identifies a section. A link navigates. A button performs an action. A label names a form control. Landmarks expose the page’s major regions.
CSS can make a generic element resemble any of these patterns, but appearance does not create the same browser behavior or programmatic relationship. Semantic choices help keyboard users, screen-reader users, search systems, reader modes, testing tools, and future maintainers interpret the same document.
This does not mean replacing every div. A generic container is appropriate
when no semantic element matches. The review question is whether meaningful
structure exists where the content or interaction requires it.
Review in layers
Begin with facts and page purpose. Remove invented testimonials, credentials, prices, locations, guarantees, or submission claims. Confirm that the main action has a real destination and that privacy language matches actual data behavior.
Next inspect document structure. Check the page language, title, heading hierarchy, landmarks, link destinations, labels, button types, image alternatives, and source order. Validate code, but remember that syntactic validity does not prove a useful interaction.
Then exercise behavior. Use only a keyboard. Test narrow reflow, enlarged text, reduced motion, errors, empty states, slow loading, disabled scripts, and a representative screen-reader flow. Inspect the real public URL for status, HTTPS, canonical metadata, crawler files, analytics boundaries, and rollback.
Keep evidence attached
A trustworthy review states what was tested, where, when, and with which limitations. Automated accessibility checks can identify important defects, but they do not replace keyboard or assistive-technology testing. A successful build does not prove that the public domain serves the tested artifact.
Store deterministic tests near the code, sources near material claims, and review dates near published content. When a correction changes substance, update the evidence and review date rather than silently rewriting history.
A controlled AI-assisted workflow
Use an assistant to narrow uncertainty, not hide it:
- Define the job, audience, facts, and constraints.
- Ask for a plan before code.
- Generate the smallest useful layer.
- Review semantics and factual integrity.
- Test behavior and failure states.
- Verify the public artifact.
- Record unresolved limits and corrections.
The goal is not to avoid AI-generated code. It is to keep an accountable owner in control of what the page claims while requiring observable evidence for what the implementation does.