Coding HTML5 Markup
Given an instruction like "create a responsive login form with accessible labels", produce:
- Semantic, accessible HTML5 markup
- A patch report documenting changes and assumptions
- Validation confirming 0 errors / 0 warnings before calling the work done
HTML<form aria-label="Login" method="post" action="/login"> <label for="username">Username</label> <input id="username" name="username" type="text" autocomplete="username" required> <label for="password">Password</label> <input id="password" name="password" type="password" autocomplete="current-password" required> <label for="remember"><input id="remember" type="checkbox" name="remember"> Remember me</label> <button type="submit">Login</button> </form>
Only deliver a final "patched" package when validation passes with zero errors and zero warnings.
- Semantics first: use
header,nav,main,section,article,footerover genericdivs. - Accessibility by default: add
label,aria-*,role,alt, and skip links proactively, not just when asked. - Minimal change: modify only what the instruction requires. Any extra change must be called out explicitly.
- Validation gate: never present markup as "done" if it has validator errors/warnings — fix first, then report status honestly.
- Transparent reasoning: document every non-obvious choice (placeholder URLs, assumed alt text, added doctype/charset).
Progress:
- Parse instruction — identify operation (create/insert/replace/remove/wrap), target elements, and ambiguity level
- Check structural basics —
<!doctype html>,<html lang>,<meta charset>,<title>present or added - Plan the minimal diff — list exactly what will change and why
- Generate markup — semantic HTML5 + accessibility attributes
- Static checks — balanced tags, no duplicate IDs, valid attributes
- Validate — run through W3C HTML5 validation logic mentally or via tool; fix issues; repeat until clean
- Report — summarize before/after, assumptions, accessibility notes, validation status
Ambiguity handling: if the instruction is contradictory or high-risk (e.g., "remove all forms" on a file with unrelated forms), ask for confirmation rather than guessing.
Accessibility defaults to apply even if not requested:
- Every
imggetsalt(empty stringalt=""if decorative/unknown, flagged for review if content is unclear) - Every form input gets an associated
label - Navigation gets
aria-labeland a skip link when it's a primary nav - Interactive elements are keyboard-operable (real
button/a, notdiv onclick)
Example 1: Input: "add a top navbar with Home, About, Contact and a skip link" Output:
HTML<a class="skip-link" href="#main">Skip to content</a> <nav aria-label="Main navigation"> <ul> <li><a href="/home">Home</a></li> <li><a href="/about">About</a></li> <li><a href="/contact">Contact</a></li> </ul> </nav>
Note: Skip link added proactively for accessibility even though not explicitly requested.
Example 2:
Input: "change title to Dashboard"
Output: <title>Dashboard</title> — single-line diff, no other changes made.
Example 3:
Input: "ensure all images have alt text" (on <img src="hero.jpg">)
Output: <img src="hero.jpg" alt="">
Assumption disclosed: actual image content is unknown, so decorative-empty-alt was used; flagged for human-authored descriptive text if the image is meaningful.
- Prefer external CSS/JS references; only inline for tiny demo snippets or when explicitly requested.
- Keep IDs unique across the document; if injecting new elements, suffix generated IDs to avoid collisions.
- When adding required boilerplate (doctype, charset, lang), state clearly that it was added and why.
- When the user's intent is underspecified (e.g., no backend URL for a form), use an obvious placeholder (
/login) and say so — don't silently invent behavior. - Preserve user's existing inline scripts/styles unless asked to change them.
- Don't claim markup is "valid" or "complete" without actually checking tag balance, required attributes, and duplicate IDs.
- Don't remove or restructure untouched content "for cleanliness" — that's scope creep; only touch what's targeted.
- Don't inject third-party resources (CDNs, analytics, fonts) without the user asking for them.
- Don't invent descriptive
alttext for images you can't actually see/inspect — use empty alt and flag it instead of guessing content. - Don't silently resolve contradictory instructions — surface the conflict.