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.
- 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.
Where first drafts commonly fail
Generated interfaces often flatten every responsibility into generic containers
because that shape is easy to style. A clickable card becomes a div with an
event handler; a section title becomes bold text; a field uses placeholder text
as its label; a navigation change is implemented without an addressable link.
Each shortcut adds review work because the browser can no longer supply its
native contract.
Other defects hide behind correct elements. A button inside a form may submit because its type was omitted. A dialog may use the native element but open without a name or focus return. A responsive grid may display the desired desktop screenshot while CSS reordering creates a different keyboard sequence. Semantic review therefore combines element choice with context, state, and behavior.
Generated copy creates a parallel risk. The page may claim that a message was sent even though no endpoint exists, present invented customer evidence, or describe tracking that differs from the actual scripts. Review visible claims, metadata, structured data, legal text, and network behavior as one system. A truthful interface is part of technical correctness.
Make the review reproducible
Turn findings into small observations another person can repeat. “The menu is inaccessible” is too broad. “At 320 CSS pixels, open the menu, press Tab six times, and focus moves to the hidden page behind the overlay” identifies route, state, input, and failure. The correction can then change focus containment and add a regression for that exact contract.
Use browser tools to inspect the live DOM and accessibility tree, not only the component source. Parser recovery, conditional rendering, CSS, and script state can produce a different result from the file under review. Compare normal, loading, empty, invalid, success, and failure states. Repeat after a full reload and direct deep link so client navigation does not hide server or route defects.
Attach evidence proportionately. Unit tests suit deterministic compilers and schemas. Browser journeys suit focus, reflow, copy, and navigation. Manual screen-reader evidence covers reading and interaction that automated rules cannot prove. Production smoke and logs cover the deployed boundary. None of these replaces the others.
Decide when not to generate
Generation is a poor shortcut when the missing work is a factual decision, legal promise, security boundary, or product policy. An assistant can draft a schema or checklist, but the accountable owner must decide what data is collected, who may access it, what a product costs, when a refund applies, and which claims have support.
It is also reasonable to keep native markup instead of generating a custom
component. details, dialog, form controls, links, buttons, tables, media
controls, and responsive images already encode substantial browser behavior. Use
custom code when a documented task exceeds the native pattern and the team can
maintain the added keyboard, focus, state, security, and compatibility surface.
The practical standard is not whether a human or model typed each line. It is whether the final artifact has a truthful owner, bounded scope, primary sources, observable behavior, regression protection, and a recovery path when reality differs from the draft.