Semantic HTML

Semantic HTML means using HTML elements for their intended purpose. <button> for buttons, <nav> for navigation, <article> for article content. Not <div class="button">, not <span class="nav">, not <div class="article">.

Sounds simple, right? Yet most modern web development ignores semantics entirely. Divs everywhere, JavaScript frameworks that output meaningless markup, component libraries that prioritize flexibility over meaning.

Here's why semantic HTML matters: assistive technologies rely on HTML semantics to understand page structure and meaning. Screen readers announce "button" when encountering <button>, "navigation region" for <nav>, "heading level 2" for <h2>. They announce nothing for <div onclick="...">.

Semantic HTML is the foundation of accessibility. ARIA and other techniques can patch gaps, but nothing replaces proper HTML. Start with semantics, enhance with ARIA only when necessary.

HTML has over 100 elements. Most developers use about 10. Here are the semantic elements that matter for accessibility:

Document Structure:

• <header>: Page or section header (not just any heading)
• <nav>: Navigation landmark
• <main>: Primary page content (only one per page)
• <article>: Self-contained content (blog post, product, comment)
• <section>: Thematic grouping of content with a heading
• <aside>: Tangentially related content (sidebar, pullquotes)
• <footer>: Page or section footer

Text Content:

• <h1> through <h6>: Headings (hierarchical, never skip levels)
• <p>: Paragraphs (not divs with text in them)
• <ul> / <ol> / <li>: Lists (navigation menus are lists)
• <blockquote>: Quoted content
• <cite>: Citation or reference

Interactive Elements:

• <button>: Buttons (for actions)
• <a>: Links (for navigation)
• <input>, <select>, <textarea>: Form controls
• <label>: Form field labels
• <form>: Form grouping

Embedded Content:

• <img>: Images (with alt text)
• <figure> / <figcaption>: Images with captions
• <video> / <audio>: Media (with controls)
• <iframe>: Embedded content (with title)

Using these correctly gives you accessibility for free. Screen readers understand them. Keyboard navigation works automatically. Search engines index better. Styling is easier with semantic selectors.

Div-itis: the overuse of non-semantic <div> and <span> elements when semantic alternatives exist.

Bad:

<div class="header">
  <div class="nav">
    <div class="menu-item" onclick="...">Home</div>
  </div>
</div>
<div class="content">
  <div class="article">
    <div class="title">Article Title</div>
    <div class="body">Content here</div>
  </div>
</div>

Good:

<header>
  <nav>
    <ul>
      <li><a href="/">Home</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>Article Title</h1>
    <p>Content here</p>
  </article>
</main>

The semantic version:

• Works with screen readers out of the box
• Allows landmark navigation (jump directly to nav, main, etc.)
• Provides clear document structure
• Requires no ARIA patches
• Is easier to style (nav ul li instead of .nav .menu-item)

Divs aren't evil – they're for grouping when no semantic element fits. But they're the last resort, not the default.

Headings (<h1> through <h6>) structure your content hierarchically. Screen reader users rely heavily on headings to navigate and understand page organization. Most screen reader users navigate by headings as their primary method of scanning content.

Heading Rules:

• One <h1> per page (the page title)
• Never skip heading levels (h2 after h1, h3 after h2, etc.)
• Headings describe the content that follows
• Every page section should have a heading
• Don't use headings for visual styling (use CSS instead)

Common Mistakes:

• Multiple <h1> tags (confuses document structure)
• Jumping from <h1> to <h3> (skips h2 level)
• Using <h3> because it "looks right" visually
• No headings at all, just styled divs
• Headings that don't describe content ("Lorem Ipsum", "Section 1")

Testing Headings:

• Pull up heading structure in browser DevTools accessibility panel
• Should read like a table of contents
• Every section of content should appear
• Hierarchy should be logical

Headings are so important that fixing heading structure often makes more impact than any other single accessibility improvement. They're the roadmap users follow through your content.

Buttons and links are not interchangeable. They have different purposes, behaviors, and meanings:

Use <a> (links) for navigation:

• Takes you to a different page or location
• Has an href attribute
• Opens in new tab/window when requested
• Bookmarkable destination
• Activated with Enter key
• Example: "Read more", "About Us", "View Product"

Use <button> (buttons) for actions:

• Triggers JavaScript functionality
• Stays on current page (or submits form)
• No href attribute
• Does something (opens modal, submits form, adds to cart)
• Activated with Enter AND Space keys
• Example: "Add to Cart", "Show More", "Close Dialog"

Common Mistakes:

• <a href="#" onclick="...">: Should be a button
• <button onclick="location.href='...'">: Should be a link
• Styled links that look like buttons (confusing semantics)
• Buttons with href (invalid HTML)

Testing: Ask: "If JavaScript failed, where should this take me?"

• Somewhere specific? It's a link.
• Nowhere / should do nothing? It's a button.

Get this right and you've fixed multiple accessibility issues at once: keyboard support, screen reader announcements, user expectations all align.

Forms have strict semantic requirements for accessibility:

Every input needs a label:

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

Or wrap the input:

<label>
  Email Address
  <input type="email" name="email">
</label>

Do not use:

• Placeholder text as labels (disappears when typing)
• Title attributes (not reliably announced)
• Adjacent text without <label> (not programmatically associated)

Grouping related fields:

<fieldset>
  <legend>Shipping Address</legend>
  <!-- address fields here -->
</fieldset>

Radio buttons and checkboxes:

<fieldset>
  <legend>Contact Preference</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
</fieldset>

Required fields:

<label for="name">Name <span aria-label="required">*</span></label>
<input type="text" id="name" required>

Or:

<label for="name">Name</label>
<input type="text" id="name" aria-required="true">

Semantic forms work with autofill, password managers, assistive technology, and voice control. Non-semantic forms break all of these.

How to audit and improve your HTML semantics:

Browser DevTools:

• View Document Outline (shows heading structure)
• Accessibility panel (shows semantic roles and names)
• Lighthouse audit (flags missing semantics)

Screen Reader Testing:

• Navigate by headings (H key in NVDA/JAWS)
• Navigate by landmarks (D key)
• Navigate by form elements (F key)
• If navigation is confusing or incomplete, semantics are wrong

HTML Validator:

• validator.w3.org checks HTML validity
• Invalid HTML often means semantic errors
• Fix validation errors first

Manual Review:

• Could this div be a semantic element?
• Are headings hierarchical and descriptive?
• Do interactive elements use button/link appropriately?
• Are lists marked up as lists?
• Do forms use proper labels and fieldsets?

Refactoring Strategy:

1. Start with document structure (header, nav, main, footer)
2. Fix headings (ensure hierarchy and completeness)
3. Replace interactive divs with buttons/links
4. Properly mark up forms
5. Use semantic text elements (lists, blockquotes, etc.)
6. Only then add ARIA if gaps remain

Semantic HTML provides significant accessibility benefits with relatively modest effort. Get the semantic structure right and most other accessibility issues become easier to solve.