Semantic HTML Validator

Semantic HTML: Writing Markup That Means Something

HTML is more than a styling vehicle. The elements you choose communicate meaning to browsers, screen readers, search engines, and the next developer. <button> says "this is interactive and clickable." <article> says "this is a self-contained piece of content." <nav> says "this is navigation." <div> says nothing. Choosing the right element costs nothing and gives a lot.

The Landmark Elements

HTML5 introduced semantic landmark elements that screen readers and search engines treat specially:

A typical blog post page:

Notice:

• The page has site-level <header> and <footer>.
• <main> contains the unique-to-this-page content.
• The article has ITS OWN <header> and <footer> (post title/byline, post tags).
• <aside> for the related-posts sidebar.

A screen reader user can press their landmark shortcut and jump straight to <main>, skipping the site nav.

Section vs Div vs Article

The most confused trio.

<article>, a self-contained piece of content that could stand alone. If you could RSS-syndicate it, it's an article. Examples: blog posts, forum messages, comments, product cards, magazine columns.

<section>, a thematic grouping of content with a heading. Examples: chapters of a book, tab panels, dashboard widgets, FAQ sections. Should always contain a heading element (h1-h6).

<div>, a generic grouping with no semantic meaning. Use when none of the above fits. Don't be afraid of <div>, it's correct when no semantic exists. <div> for styling/layout wrappers is honest; <section> for the same is misleading.

Test: would the element belong in a table of contents? Use <section> or <article>. Otherwise <div>.

Interactive Elements

The most-misused element on the web: <div onClick>. It works visually but:

• Not keyboard-accessible (Tab won't reach it, Enter won't activate it).
• Not announced as interactive by screen readers.
• No focus indicator.
• No form-submit behavior.

The correct element depends on what it does:

Using <button> instead of <div onClick> gets you: keyboard activation, focus visible, screen-reader announcement ("button"), submit behavior if in a form, hover/active states from browser defaults.

Heading Hierarchy

Headings form the page outline. Rules:

1. One <h1> per page (the page title).
2. Don't skip levels going down: h1 → h2 → h3, not h1 → h4.
3. Skipping levels going up is fine: h3 → h2 (starting new section).
4. Each landmark/article can have its own heading hierarchy.

Example outline:

Screen reader users can list all headings, it's effectively the TOC of the page. Skipping levels (h1 → h3) confuses the outline.

CSS appearance is separate. A <h2> styled to look like 14px body text is still semantically an h2.

ARIA: Use Sparingly

ARIA (Accessible Rich Internet Applications) attributes give roles, states, and properties to elements that don't have them natively.

The rule (from W3C ARIA Authoring Practices Guide): "The first rule of ARIA is: don't use ARIA."

If a native element does the job, use it. ARIA is for:

• Custom widgets (a custom tab system, accordion, dialog).
• Live regions (aria-live for dynamic content updates).
• Additional context (aria-label on icon-only buttons, aria-describedby for help text).
• State indication (aria-expanded, aria-checked, aria-selected).

Common ARIA mistakes:

• <button role="button">, redundant; button already has role button.
• <a role="button">, change behavior expectations (Enter activates, Space doesn't). Just use <button>.
• role="navigation" on a <nav>, redundant.
• <div role="button" tabindex="0">, reinventing <button> poorly; missing keyboard handling, missing default styling.
• aria-hidden on focusable elements, broken: screen reader skips but keyboard focuses, confusing.

When in doubt, use the native HTML element. Reach for ARIA only when you've established that no HTML element fits.

Common Anti-Patterns

Div Soup

Should be:

Fewer divs, more meaning, accessible by default.

Heading Used as Styling

If it's not part of the outline, don't use a heading. Use a <p> styled appropriately.

Inverse: Styling Used as Heading

Screen readers see nothing special. Use <h2> or <h3>.

Form Without Labels

Placeholder is NOT a label, it disappears on input, fails contrast in many browsers. Use:

Or:

Images Without Alt

Screen readers will say "image" with no context. Add:

For decorative-only images:

Empty alt tells screen readers to skip, better than no alt (which announces filename).

Tables for Layout

<table> is for tabular data only. Use CSS grid/flexbox for layout. Screen readers announce tables as data tables, confusing users when there's no data.

Forms

Forms have their own semantic structure:

Notes:

• <fieldset> + <legend> groups related inputs.
• Every input has a <label> linked by for/id.
• <button type="submit"> for the submit button (not <input type="submit">, less stylable).
• required, type="email", minlength are validation attributes, free browser validation.
• aria-describedby links help text to the input.

SEO Benefits

Search engines parse semantic HTML to understand content structure:

• Schema.org microdata in semantic elements helps rich results.
• Headings form the document outline; main heading often becomes the result title.
• <article> signals "this is the main content unit", useful for article-style search results.
• <nav> lets crawlers identify nav vs content (so they don't index repeated nav links as content).
• <main> identifies the primary content area, sometimes used for snippet extraction.

Privacy

Validation runs entirely in your browser using the native DOMParser API. Your HTML, sometimes containing internal admin UIs, draft pages, or proprietary widgets, stays in the tab. Open DevTools Network during use: zero outbound requests. Important because pasted HTML can reveal unreleased features (URL structures, component patterns) that shouldn't be analyzed by third-party services.