Cart

[lsft_horizontal_flags]

Semantic HTML in WordPress Themes: How to Fix Structure and Headings

Semantic HTML is the backbone of accessibility in WordPress themes.
Before ARIA roles, before plugins, before audits, accessibility starts with clean and predictable markup.
Unfortunately, many WordPress themes — especially commercial ones — treat HTML as a styling tool rather than a semantic language. There are various reasons why this happens:
Direct Control Over Design: Using inline styles or HTML attributes allows developers to have immediate visual changes without the need to modify CSS files. This can speed up the design process.
Simplicity for Non-Developers: Many users of commercial themes may not have extensive coding knowledge. By embedding styles directly within the HTML, theme authors can create a more user-friendly experience, allowing users to easily tweak styles without needing to dive into CSS.
Legacy Support: Some authors might still follow older practices where inline styles were more common, believing it allows for broader compatibility across various browsers and devices.
Performance Optimization. For small, specific changes, embedding styles directly in the HTML can sometimes reduce the number of HTTP requests made to load styles from separate CSS files.
Quick Prototyping. Using HTML for styles can make it faster for developers to prototype and test designs, leading to quicker iterations.
User Customization. It allows users to make adjustments directly (e.g., through WordPress’s block editor) without needing to write additional CSS, thus making the theme more flexible.
Despite these advantages, this approach may lead to issues such as reduced semantic meaning in code, potential accessibility problems, and challenges in maintaining and scaling styles across large projects.
The result is a site that looks fine but breaks for screen readers, keyboard users, and search engines.
Let’s focus on the structural elements that matter most.

Semantic HTML in WordPress Themes: How to Fix Structure and Headings

One <h1> Per Page: When and Where

The Golden Rule of Semantic HTML: a page should have one logical <h1>, representing the main topic of the page.

Best practice

  • The <h1> usually corresponds to:
    • the post title in single.php
    • the page title in page.php
  • It should appear inside the main content, not in decorative areas

Common mistakes

Multiple <h1> used for layout purposes
Logo or site name wrapped in <h1> on every page
Heading levels skipped for visual reasons (<h2> → <h4>)

A simple rule:

If removing CSS breaks the meaning of your headings, the structure is wrong.

Using <main> Correctly in WordPress Templates

The <main> element defines the primary content of the page.
Screen readers rely on it to jump directly to what matters.
Semantic HTML is crucial for accessibility

Where <main> belongs

One <main> per page
Wraps the central loop output
Excludes headers, footers, and sidebars

How to interpret Typical placementthe score

Open <main> in page.php, single.php, or index.php
Close it before loading the footer

What to avoid

Multiple <main> elements
<main> inside <article>
Using <div id="main"> instead of the real element
Using <main> correctly also makes “Skip to content” links work as intended.

Common Structural Errors in Commercial Themes which fail to use semantic HTML

Many premium themes break semantic structure in predictable ways:
Headings used purely for styling
Missing landmark elements (main, nav)
Navigation menus built with non-semantic <div> structures
Content order that makes sense visually but not logically
These issues are often invisible until you:
test with a keyboard
inspect the DOM
use a screen reader
Fixing them usually requires template edits, not plugins.

ARIA Roles: When to Use Them (and When Not To)

ARIA is often added as a band-aid for poor HTML.
That’s the wrong approach.

Use ARIA when:

You’re building custom interactive components
Native HTML elements are not sufficient
You understand the role and its implications

Avoid ARIA when:

A native element already exists (button, nav, main)
You’re adding roles “just in case”
You’re trying to fix broken markup
Rule of thumb:

No ARIA is better than wrong ARIA.

Why This Matters Beyond Accessibility

Correct semantic structure:
improves screen reader navigation
makes keyboard testing predictable
helps search engines understand content hierarchy
reduces the need for ARIA and JS hacks
In WordPress, theme structure is accessibility.
Get that right, and everything else becomes easier.

🔗 This article is part of a broader guide on the most critical accessibility areas in WordPress: 6 Expert Techniques to Enhance Accessibility in WordPress

«

Leave a Reply

Your email address will not be published. Required fields are marked *