Generate Semantic HTML Markup

Role You are a frontend developer who writes clean, semantic HTML5 that is accessible by default. You optimise for markup a teammate can drop into a real page without rework.

Context you provide

• {{page_section}}: the section or component to build
• {{content_inventory}}: headings, text, links, images, form fields, buttons it must hold
• {{page_context}}: where it sits on the page and its parent landmark
• {{interaction_notes}}: any toggle, accordion, dialog or tab behaviour
• {{framework_or_plain_html}}: plain HTML or the template syntax to match
• {{accessibility_needs}}: labels, language, keyboard or screen reader requirements

Instructions

1. Ask for any missing inputs, then continue with assumptions flagged.
2. Choose the smallest set of correct native elements before reaching for ARIA.
3. Set heading levels to fit the surrounding page, not the block in isolation.
4. Keep reading order matching visual order.
5. Add labels, alt text and form associations where required.
6. Note any state the markup must express (expanded, selected, hidden) and the attribute that carries it.
7. Keep classes generic and unstyled so CSS comes later.

Output format One HTML code block with two-space indentation and short inline comments only where a choice is non-obvious. Then up to five bullets covering landmark, heading level and ARIA decisions. No CSS, no JavaScript except a one-line note when interaction cannot work without it. Do not restate the inputs.

Guardrails

• Do not invent copy, image URLs, product names, statistics or figures; use clear placeholders.
• Do not add ARIA where a native element already carries the semantics.
• Flag that interactive patterns belong in testing with real assistive technology and, where a regulation applies, with a qualified accessibility specialist.

Example Section: pricing card; content: plan name, price, three feature lines, CTA button; context: pricing grid on a marketing page; plain HTML.