Semantic HTML is the practice of marking up web content with elements that describe what the content is, not how it should look. In HTML, a heading is marked as a heading, a list as a list, navigation as navigation and a button as a button, so that browsers, assistive technologies, search engines and other programs can interpret the structure and purpose of a page.
The opposite is presentational or generic markup, where everything is built from div and span elements styled to look right. Such a page may appear identical on screen, but its meaning exists only visually, and every program that reads the code receives far less information.
How semantic elements convey meaning
Every HTML element has a defined meaning in the HTML Living Standard, and browsers map many of them to implicit accessibility roles. A nav element becomes a navigation landmark, an h2 becomes a level-two heading, and a button becomes a focusable control that responds to the keyboard.
This mapping is why semantic HTML provides functionality for free. The browser adds keyboard behavior, focus handling and role information that would otherwise have to be rebuilt with JavaScript and ARIA attributes.
| Element | Meaning | Implicit role or behavior |
|---|---|---|
header | Introductory content for a page or section | Banner landmark at page level |
nav | Major navigation links | Navigation landmark |
main | Primary content of the page, used once | Main landmark |
article | Self-contained composition | Article role |
aside | Tangentially related content | Complementary landmark |
footer | Closing information for a page or section | Content information landmark at page level |
h1 to h6 | Heading hierarchy | Heading role with level |
button | Action control | Focusable, activates with Enter and Space |
Text-level and structural semantics
Semantic HTML is not limited to page regions. Text-level elements carry meaning inside paragraphs, and structural elements describe relationships between pieces of content.
| Element | Correct meaning | Often misused instead of |
|---|---|---|
strong | Strong importance | Bold styling only, which belongs in CSS |
em | Stress emphasis that changes meaning | Italic styling only |
a with href | Navigation to a resource | A button that performs an action |
button | Action on the current page | A link styled as a button |
ul or ol | Group of related items | Separate paragraphs or line breaks |
table | Two-dimensional data | Page layout |
label | Name of a form control | Placeholder text |
The link versus button distinction is the most consequential in practice. Links navigate to a URL and appear in link lists; buttons trigger actions such as submitting, opening or toggling. Mixing them breaks expectations for keyboard and screen reader users.
Why semantic HTML matters
Semantic markup serves several independent consumers of the same page. The benefit is cumulative, because one correct element improves accessibility, search visibility and maintainability at the same time.
| Consumer | What it gains | Effect |
|---|---|---|
| Screen readers | Landmarks, headings, roles and names | Fast structural navigation |
| Keyboard users | Native focus and activation | Controls usable without a mouse |
| Search engines | Clear headings and main content | Better understanding of page topics |
| Reader modes and AI parsers | Identifiable article content | Cleaner extraction and summaries |
| Developers | Self-describing code | Easier maintenance and styling |
Semantic HTML is the foundation of several WCAG success criteria, particularly those on info and relationships and on name, role and value. Most automated accessibility audits flag non-semantic controls as their most frequent issues.
Semantic HTML compared with ARIA and generic markup
ARIA attributes can add roles and states to any element, but they do not add behavior. A div with a button role still needs focus handling and keyboard events written by hand, which makes it more fragile than the native element.
The widely accepted first rule of ARIA is therefore to use a native HTML element with the required semantics whenever one exists. ARIA is appropriate for complex widgets without native equivalents, such as tabs or tree views, and for describing dynamic states.
- Native element: built-in semantics, behavior and styling hooks; the preferred choice.
- Native element plus ARIA: adds states such as expanded or current that HTML cannot express.
- Generic element plus ARIA: possible but requires manual focus, keyboard and state management.
- Generic element alone: no meaning for assistive technology; should be avoided for content and controls.
Common mistakes in semantic markup
Semantic errors are easy to make because visual output hides them. The page looks correct, so the problem appears only to assistive technology, search engines or automated tools.
- Choosing headings by size: heading levels must reflect hierarchy, while size is set in CSS.
- Skipping heading levels or using several unrelated
h1elements in complex layouts. - Clickable div elements instead of buttons or links.
- Overusing section elements without headings, which adds noise without structure.
- Layout tables that make screen readers announce rows and columns that carry no data.
- Placeholder as label, which disappears on input and is not a reliable accessible name.
A practical test is to view the page without CSS. If the content still reads as a logical document with clear headings, lists and controls, the markup is usually semantic enough.
In everyday language
Semantic HTML means labeling each part of a web page for what it really is. A title is marked as a title, a menu as a menu and a button as a button, instead of making everything look right with styling alone.
Think of a well-organized book with a table of contents, chapters and an index. People and machines can find their way around quickly. A page built without these labels is like a book with no chapters, readable for some but confusing for anyone who relies on structure.
Seen in the real world
A municipal website lists public notices on a page built entirely from generic containers. The visual design is clear, but a screen reader announces it as one long block of text with no headings, and the “Open” controls cannot be reached with the Tab key.
A front-end developer rebuilds the template with header, nav, main and footer landmarks, turns each notice into an article with an h2 heading, and replaces the clickable containers with real links to each notice. The CSS changes only slightly, so the page looks almost the same.
After the update, keyboard and screen reader users can jump directly between notices, an accessibility audit no longer reports structural errors, and search results begin to display the notice titles more accurately.