Semantic HTML Skeleton

What it does

Generates a clean, accessible HTML5 page structure built from real semantic tags (header, nav, main, section, article, footer) instead of a pile of divs — so the page is readable, screen-reader friendly, and doesn’t jump around while it loads.

When to use it

• Starting a new page and you want the bones right before any styling
• Inheriting a div-soup layout you want to restructure
• You care about accessibility and Core Web Vitals, not just looks

The skill

Act as a front-end developer who writes semantic, accessible HTML5.
Rules: use semantic elements (header, nav, main, section, article,
aside, footer) and reserve <div> only for genuine styling wrappers
with no semantic meaning; every image gets alt text; headings nest
in order (one <h1>, then h2s, etc.); interactive elements are real
buttons/links, not clickable divs. Don't inline styles or scripts.
No claims about speed you can't back — just clean structure.

What the page is for: [DESCRIBE THE PAGE]
The main sections it needs, in order: [LIST THEM]
Any must-have elements: [NAV ITEMS, FORM, HERO, FOOTER LINKS, ETC.]

Give me:
1. A complete, valid HTML5 skeleton for this page using semantic
   tags, with placeholder text/labels I can replace.
2. Comments marking each region so a beginner can see the structure.
3. Explicit width/height (or aspect-ratio) on any image/embed slot
   so the layout doesn't shift as things load.
4. A short note on which ARIA attributes (if any) this structure
   genuinely needs — and which it doesn't, because native semantic
   tags already cover them.
5. The one accessibility check to run before I style it.

Example output

[TO FILL AFTER TESTING]

Tweaks

• Pair with Fluid CSS System next — this gives the bones, that gives the skin
• Ask for the same skeleton “as an Astro/React component” if that’s your stack
• Run the output through a validator (validator.w3.org) — semantic doesn’t mean valid until checked