Semantic HTML: The Effortless Foundation of Web Accessibility

Have you ever opened a website with a screen reader and heard nothing but “div, div, div, link, div”? We hear it often. And it's not a mistake of the user — it's a mistake of the developer. When a site is entirely made of <div> and <span>, a screen reader has to guess the structure. The good news? The solution is already built into HTML5: semantic markup. And it costs nothing. Zero plugins, zero extra libraries. Just the right tags. We at Meteora Web work on this every day: we come from accounting and bookkeeping, and we know that accessibility is not an extra — it's an investment that reduces bounce rate, improves SEO, and expands your market. Let's start with the concrete problem: is your site understandable to a robot? And to a blind person? If the answer is “maybe”, this guide is for you.

Why Semantic HTML Is the Foundation of Accessibility

Imagine entering a store where all products are in unlabeled white boxes. You have to open each box to know what's inside. Frustrating, right? That's exactly how a non-semantic website feels for assistive technology users. HTML5 tags like <nav>, <main>, <article>, <aside>, <header>, <footer> give meaning to page sections. Not only for people with disabilities: Google uses them to understand structure and rank better. We've seen clients gain positions just by cleaning up their markup — no extra backlinks.

At Meteora Web, when we take over an old project, the first thing we check is the heading hierarchy and implicit ARIA landmarks. Often we find missing <h1> or five <h1> on the same page. Fixing these doesn't take hours, but it makes the difference between an excluding site and an inclusive one.

ARIA Landmarks and HTML5 Tags

ARIA landmarks (Accessible Rich Internet Applications) tell the screen reader: “Here is navigation”, “Here is main content”, “Here is a complementary section”. The best practice is to use the HTML5 tags directly, which carry implicit ARIA roles. For example:

<nav> … </nav>  // implicit role “navigation”
<main> … </main>  // implicit role “main”
<aside> … </aside> // implicit role “complementary”

If for design reasons you cannot use the exact tag, you can manually add the role: <div role="navigation">. But native tags are cleaner, easier to maintain, and avoid future CSS or JS conflicts.

Common mistake: wrapping everything in <div> and then adding role="main" on a div. It works, but it's like using duct tape to fix a pipe: it holds, but it's not the right solution. Use <main> once per page.

Heading Hierarchy: The Page Map

Headings (<h1> – <h6>) aren't just for making text bigger. They are the navigation anchors for screen readers. Users can jump from heading to heading, like a table of contents. If the hierarchy is broken (e.g., an <h3> after an <h1> without an <h2> in between), the screen reader cannot build a logical structure.

Practical Rule for Hierarchy

• One and only one <h1> per page (usually the site name or page title).
• Then <h2> for main sections.
• Then <h3> for subsections, and so on.
• Don't skip levels: don't go from <h2> to <h4> without an <h3>.

A real example from an e-commerce client: the product page had an <h1> with the product name, then directly an <h4> for “Description”. Changing it to <h2> for the description section helped the screen reader navigate better, and the client saw an increase in average time on page. Not a direct causal link, but usability definitely improved.

Forms: Labels, Placeholders, and Error Messages

Forms are often the weakest point of accessibility. We see it in projects that come to us: fields without <label>, placeholders used as labels, error messages that appear only visually. For a screen reader, a field without a label is like a door without a handle: you don't know what's behind it.

The rule is simple: every <input>, <select>, <textarea> must have an associated <label> — either via the for attribute or by wrapping the field inside the <label>. Example:

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

For error messages, link them with aria-describedby:

<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email address</span>

Beware of placeholders: don't use them as the only label. Placeholders disappear when the user types, making them inaccessible for people with memory issues or screen reader users. Labels should always be present and visible.

Images: Alt Text Is Not Optional

The alt attribute provides alternative text for people who cannot see the image. Don't leave it empty unless the image is purely decorative (in that case alt="" tells the screen reader to ignore it). Don't stuff it with keywords: describe what the image communicates that is important for the context. Example:

<!-- Decorative image -->
<img src="decorative.jpg" alt="">

<!-- Informative image -->
<img src="sales-chart.png" alt="Bar chart of 2025 sales by quarter: Q1 120k, Q2 150k, Q3 170k, Q4 200k">

A common mistake: linked images without description. If an image is a link, the alt text must describe the link destination, not the image. Example: <a href="/contact"><img src="phone.png" alt="Contact us"></a>.

Buttons and Links: Don't Confuse Them

A <button> is for actions (submit a form, open a modal). A <a> is for navigating to another page. It sounds obvious, but many sites use clickable <div> with JavaScript to fake buttons. This is problematic for screen readers because they don't know the element is interactive. Always use the native tag: <button> or <a> with href. If you need a custom design, apply role="button" and handle Enter and Space key presses with JavaScript.

Language and Reading Order

Specify the page language with the lang attribute on the <html> element:

<html lang="en">

If a block of text is in another language, use lang there too: <p lang="fr">Ceci est en français</p>. This tells the screen reader which voice to use.

Also, the reading order must match the visual order. Don't use CSS to visually reorder elements that are in a different order in the HTML: screen readers follow the DOM order. Verify with tools like the W3C validator or the Axe browser extension.

Immediate Checklist for Your Site

Pick one page from your website and check these points:

• Landmarks: are there <nav>, <main>, <header>, <footer>?
• Headings: one <h1> and no skipped levels?
• Forms: every field has an associated <label>? Error messages readable?
• Images: all informative images have descriptive alt? Decorative ones have alt=""?
• Buttons/Links: do you use <button> for actions and <a> for links?
• Language: lang on html and on blocks in other languages?

If you have even one “no”, you have an opportunity for improvement.

In a Nutshell — What to Do Now

Semantic HTML is the zero-cost foundation of accessibility. It doesn't require an extra budget — just knowledge and discipline. At Meteora Web we apply it in every project, from a small brochure site to custom Laravel platforms. Practical advice? Take your most visited page, open the browser console (F12), go to the “Elements” tab, and look at the structure. See <div> everywhere? Good, you have your weekend task: replace a <div class="nav"> with <nav>. Then repeat. One step at a time, but start now.

For a deeper dive into the whole WCAG world, read our Definitive Pillar Guide on Web Accessibility.