Common Semantic HTML Mistakes and How to Correct Them

Choose meaning before appearance

One of the most common semantic mistakes is selecting an HTML element because of its default appearance. A developer may choose an <h2> because it produces large text, use a <blockquote> to create indentation, or add a <br> element merely to produce more space.

This reverses the relationship between HTML and CSS. HTML should describe what the content represents. CSS should control how that content appears.

Before choosing an element, ask:

• What does this content represent?
• What relationship does it have to the content around it?
• Is it a heading, paragraph, list, quotation, control, navigation region, or data table?
• Would its meaning remain understandable if the page’s CSS did not load?

A semantic element can still be styled in any suitable way. A heading does not have to be large, and a button does not have to retain the browser’s default appearance. Meaning and presentation work together, but they perform different jobs.

For a broader introduction, see Semantic HTML Foundations: Structure and Meaning.

Use headings to describe structure, not text size

Headings establish the hierarchy of a document. They introduce topics and show how sections relate to one another. Screen reader users may also navigate by headings, while search and retrieval systems can use them to interpret the organization of a page.

Using a heading because it looks prominent

A heading should introduce a section or subsection. It should not be used simply to make a sentence bold or visually prominent.

<!-- Chosen primarily for appearance -->
<h3>Call today for availability</h3>

If the text is not actually a heading, a paragraph or another appropriate element can be styled to provide the desired visual emphasis.

<p class="notice">Current scheduling information is available by phone.</p>

Creating visual headings with generic elements

The opposite problem occurs when text functions as a heading but is marked up as a styled <div>, <span>, or paragraph.

<div class="large-bold-text">Aircraft Inspection Services</div>

This may look like a heading, but its structural role is absent from the HTML. When the text genuinely introduces a section, use a heading element.

<h2>Aircraft Inspection Services</h2>

Skipping heading levels without considering the hierarchy

Heading levels should reflect the nesting of the content. An <h3> normally belongs beneath an <h2>, and an <h4> normally introduces a subsection within the preceding <h3> section.

A skipped level is not automatically catastrophic, but it may indicate that the document structure has not been considered carefully. Heading levels should not be selected according to their default font size. CSS can change the appearance without changing the hierarchy.

See Heading Hierarchy for a deeper explanation of heading relationships and page structure.

Represent lists as lists

Groups of related items are sometimes created with bullet characters, hyphens, separate paragraphs, or line breaks:

<p>
• Roof replacement<br>
• Window installation<br>
• Siding repair
</p>

The content may look like a list, but the document does not identify it as one. Assistive technologies cannot reliably announce the number of items or provide list-based navigation.

Use an unordered list when sequence does not matter:

<ul>
  <li>Roof replacement</li>
  <li>Window installation</li>
  <li>Siding repair</li>
</ul>

Use an ordered list when the sequence, ranking, or progression is meaningful:

<ol>
  <li>Inspect the work area.</li>
  <li>Identify the required repair.</li>
  <li>Document the completed work.</li>
</ol>

List styling can be changed with CSS. Removing visible bullets does not remove the list’s semantic relationship, although custom styling should still leave each item visually understandable.

Use native elements for links, buttons, and form controls

Generic containers are often made clickable with JavaScript:

<div class="button" onclick="openMenu()">Open menu</div>

A mouse user may be able to activate this control, but a generic <div> does not automatically receive keyboard focus, respond to standard keyboard commands, or expose button semantics to assistive technologies.

A native button supplies those behaviors:

<button type="button" aria-expanded="false" aria-controls="site-menu">
  Open menu
</button>

Choosing between a link and a button depends on what the control does:

• Use an <a> element with an href when the user will navigate to another location or resource.
• Use a <button> when the user will perform an action, such as opening a menu, submitting information, or changing an interface state.
• Use native form controls such as <input>, <select>, and <textarea> when collecting information.

Native elements provide established browser behavior before custom scripting is added. This generally reduces the amount of keyboard handling, focus management, and accessibility repair required later.

Use generic containers intentionally

The <div> and <span> elements are not inherently unsemantic or incorrect. They are useful when HTML does not provide a more meaningful element for the purpose at hand.

A semantic problem appears when generic containers replace elements that already describe the content accurately. Examples include:

• a <div> used instead of a button;
• a styled <span> used instead of a heading;
• a series of paragraphs used instead of a list;
• a generic wrapper used where <nav>, <aside>, or <article> would clarify the region’s purpose.

The goal is not to eliminate every <div>. The goal is to avoid making generic containers carry meanings that native elements can communicate directly.

Reserve tables for tabular information

HTML tables describe relationships between data organized into rows and columns. They are appropriate for schedules, specifications, comparison data, maintenance intervals, and similar information.

Tables should not be used to position page elements or create a multi-column layout. Layout tables make the document structure harder to understand and can cause content to be announced in an unexpected order by assistive technologies.

Use CSS Grid, Flexbox, or another CSS layout method for page presentation. Use a table when the row and column relationships are part of the information itself.

A meaningful data table commonly includes:

• a <caption> that identifies the table;
• <th> elements for row or column headers;
• an appropriate scope attribute when it clarifies header relationships;
• <thead>, <tbody>, and sometimes <tfoot> for structural grouping.

<table>
  <caption>Recommended inspection intervals</caption>
  <thead>
    <tr>
      <th scope="col">Component</th>
      <th scope="col">Interval</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Oil filter</th>
      <td>At each oil change</td>
    </tr>
  </tbody>
</table>

Use description lists for real name-and-description relationships

A description list associates terms, names, or labels with one or more descriptions. It can be useful for glossaries, metadata, specifications, and other content built around meaningful associations.

<dl>
  <dt>Canonical URL</dt>
  <dd>The preferred URL for a page when multiple URLs contain substantially similar content.</dd>

  <dt>Crawlability</dt>
  <dd>The ability of a crawler to reach and process a web resource.</dd>
</dl>

A description list should not be selected merely because its default styling provides indentation. It is also not a universal replacement for every two-column arrangement. If the content is tabular, use a table. If it is a sequence of steps, use an ordered list. If the items do not have a name-and-description relationship, another structure may be more appropriate.

Avoid unnecessary ARIA when native HTML already provides meaning

ARIA can communicate roles, names, states, and relationships that are not otherwise available through native HTML. It is valuable when building interfaces whose behavior cannot be expressed completely with standard elements.

Problems arise when ARIA is added without understanding the semantics already provided by HTML.

<button role="button">Save</button>

The explicit role="button" is unnecessary because the <button> element already has that role. In more complicated cases, an incorrect role or state can conflict with native behavior and make an interface less understandable.

ARIA also does not automatically add behavior. Giving a <div> the role of button does not provide keyboard activation, focus behavior, disabled behavior, or form participation.

<div role="button">Save</div>

This element may be announced as a button, but it still requires careful scripting to behave like one. A native <button> is usually the more reliable starting point.

A useful principle is: use native HTML whenever it can express the intended meaning and behavior, then add ARIA where it provides information that HTML alone cannot provide.

This principle supports accessibility, but accessibility extends beyond markup alone. Understanding WCAG provides additional context for evaluating accessible web experiences.

Describe document regions carefully

Elements such as <header>, <footer>, <main>, <nav>, <article>, <section>, and <aside> can clarify the large-scale organization of a page. They should be chosen according to the role of the content rather than used as interchangeable replacements for <div>.

Using section elements for every wrapper

A <section> represents a thematic grouping of content and will usually have a heading. It is not necessary for every layout wrapper, styling hook, or spacing container.

Marking every link group as navigation

The <nav> element is intended for major navigation blocks. A few contextual links in a paragraph do not normally need their own navigation landmark. Too many landmarks can make page navigation more cumbersome rather than more helpful.

Using article without independent meaning

An <article> is generally suitable for content that can stand on its own or be distributed independently, such as a news story, blog post, forum entry, or product review. It is not simply a visual content box.

Adding more than one main region

The <main> element identifies the page’s primary content. A conventional page should generally expose one active main region rather than placing <main> around multiple unrelated areas.

Thoughtful document regions contribute to clearer semantic HTML and information relationships. They also help landmark navigation remain concise and useful.

Visual success is not the same as semantic success

A page can look polished while its underlying structure remains unclear. Visual inspection alone may not reveal that:

• a heading is actually a styled paragraph;
• a button is an unfocusable generic container;
• a visual list has no list semantics;
• a data table lacks identifiable headers;
• landmarks are missing, duplicated, or used without purpose;
• content order becomes confusing when CSS is unavailable.

Semantic quality becomes more visible when a page is examined in several ways. Try navigating with a keyboard, reviewing the heading outline, inspecting the accessibility tree, disabling CSS, or reading the document in source order. Each view reveals a different part of the page’s structure.

This does not mean every document must be complex. In many cases, the clearest solution is also the simplest: a heading for a heading, a paragraph for a paragraph, a list for a list, and a button for an action.

How to review semantic HTML in context

Semantic review is more useful when it follows the meaning of the page rather than becoming a search for isolated violations.

1. Identify the page’s primary purpose.
   Determine what the page helps a visitor understand or accomplish.
2. Review the heading outline.
   Check whether headings introduce real sections and whether their levels reflect the content hierarchy.
3. Examine groups and relationships.
   Look for content that should be represented as a list, description list, figure, table, quotation, or other meaningful structure.
4. Inspect interactive controls.
   Confirm that links navigate, buttons perform actions, form controls have labels, and keyboard behavior is available.
5. Review landmarks.
   Make sure major regions are identifiable without creating an excessive or repetitive landmark structure.
6. Check native HTML before adding ARIA.
   Prefer built-in elements and behaviors where they meet the interface’s needs.
7. Test beyond visual presentation.
   Use keyboard navigation, browser developer tools, automated checks, and assistive technology as complementary forms of review.

Automated validators and accessibility tools can identify certain problems, but they cannot always determine whether an element accurately represents the author’s intent. Human review remains necessary because semantics depend on context.

This kind of review also fits naturally within broader web standards and quality assurance work.

Small semantic decisions accumulate

No single generic container or imperfect heading level defines the quality of an entire website. Semantic clarity develops through many small decisions made across templates, components, navigation systems, forms, and editorial content.

Those decisions accumulate. A well-structured page becomes easier to navigate, maintain, restyle, extract, and interpret. A component built with native HTML often requires less corrective code. A clear heading hierarchy helps readers scan while giving retrieval systems a more reliable account of the page’s subjects and relationships.

This is one reason semantic HTML remains useful even as visual design and application frameworks change. Its purpose is not to satisfy a markup ritual. It is to preserve meaning as information moves through different browsers, devices, interfaces, and retrieval environments.

Frequently asked questions

Is using a div always a semantic HTML mistake?

No. A <div> is appropriate when a generic block-level container is genuinely needed and no more specific element describes the content. The mistake is using it in place of a suitable native element without a clear reason.

Does valid HTML guarantee good semantics?

No. HTML can pass validation while still communicating the wrong meaning. A valid heading may not actually introduce a section, and a valid table may still be inappropriate for layout. Validation is useful, but intent and context still require human judgment.

Does semantic HTML improve SEO?

Semantic HTML can help search and retrieval systems interpret page structure and relationships, but it is not a shortcut to rankings. Its more durable value is clearer organization, stronger accessibility, easier maintenance, and content that can be understood across different systems.