← Back to DevBytes
Developer Tutorial July 10, 2026 10 min read

HTML Accessibility: Complete Guide

Understanding HTML Accessibility

HTML accessibility is the practice of writing HTML markup that ensures web content is perceivable, operable, understandable, and robust for people with disabilities. It forms the technical foundation of the Web Content Accessibility Guidelines (WCAG) and directly impacts how assistive technologies—such as screen readers, voice recognition software, and braille displays—interpret and convey information to users.

At its core, accessible HTML leverages semantic elements, appropriate attributes, and thoughtful structure to create an inclusive experience. Every <button>, <label>, <nav>, and aria-* attribute you add contributes to a more equitable web.

Why HTML Accessibility Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Accessibility is not an optional feature; it is a fundamental requirement for modern web development. Over one billion people worldwide live with some form of disability. When HTML is written without accessibility in mind, you effectively exclude users who rely on keyboards, screen readers, or other assistive tools. Beyond ethics, there are legal implications: many countries enforce accessibility laws, and non-compliant websites face lawsuits. From a business perspective, accessible websites reach broader audiences, improve SEO through better semantic structure, and generally provide a superior user experience for everyone—including people in noisy environments, users with temporary injuries, or those simply preferring keyboard navigation.

Semantic HTML: The Backbone of Accessibility

Semantic elements communicate meaning and structure to both the browser and assistive technologies. Choosing the correct element is often the single most impactful accessibility decision you can make.

Using Landmark Elements

Landmarks divide the page into recognizable regions, allowing screen reader users to jump directly to sections they need. The primary landmark elements include:

<!-- Primary landmarks -->
<header>...</header>
<nav>...</nav>
<main>...</main>
<footer>...</footer>

<!-- Additional landmarks -->
<aside>...</aside>
<section>...</section>
<article>...</article>

<!-- The main element should appear exactly once -->
<main id="main-content">
  <h1>Page Title</h1>
</main>

Headings Hierarchy

A logical heading structure creates an outline of the page that screen readers can navigate. Always use headings sequentially without skipping levels.

<!-- Correct heading structure -->
<h1>Company Blog</h1>
  <h2>Latest Posts</h2>
    <h3>Accessibility Wins of 2024</h3>
    <h3>Building Inclusive Forms</h3>
  <h2>Categories</h2>
    <h3>Technology</h3>
    <h3>Design</h3>

<!-- Never skip heading levels like this -->
<h1>Title</h1>
<h3>Subtitle</h3> <!-- h2 is missing -->

Text Content Elements

Use semantic text elements to convey meaning beyond visual styling:

<!-- Emphasized text announces differently to screen readers -->
<p>This is <em>really important</em> and <strong>critical</strong> information.</p>

<!-- Blockquote provides attribution context -->
<blockquote cite="https://example.com/source">
  <p>Accessibility is not a feature; it is a social responsibility.</p>
  <cite>— Web Accessibility Expert</cite>
</blockquote>

<!-- Abbreviation with expanded meaning -->
<p>The <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> defines standards.</p>

<!-- Code blocks for technical content -->
<p>Install the package using <code>npm install package-name</code>.</p>

ARIA: Enhancing Semantic Information

Accessible Rich Internet Applications (ARIA) supplements HTML semantics when native elements fall short. ARIA attributes describe roles, states, and properties to assistive technologies. The first rule of ARIA is: do not use ARIA if a native HTML element already provides the needed semantics.

Roles

Roles define what an element is. Many roles are implicit through HTML elements, but custom widgets often require explicit role declarations:

<!-- Custom tab component -->
<div role="tablist" aria-label="Product Information">
  <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
    Description
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">
    Reviews
  </button>
</div>

<div role="tabpanel" aria-labelledby="tab-1" id="panel-1">
  <p>Product description content here.</p>
</div>

<div role="tabpanel" aria-labelledby="tab-2" id="panel-2" hidden>
  <p>Product reviews content here.</p>
</div>

States and Properties

States communicate dynamic changes, while properties provide additional context:

<!-- Expandable accordion -->
<button aria-expanded="false" aria-controls="faq-answer-1" id="faq-question-1">
  What is your return policy?
</button>
<div id="faq-answer-1" role="region" aria-labelledby="faq-question-1" hidden>
  <p>Returns are accepted within 30 days of purchase.</p>
</div>

<!-- Live region for dynamic updates -->
<div aria-live="polite" aria-atomic="true">
  <!-- Dynamic content updates announced by screen readers -->
  <p>Shopping cart items: 3</p>
</div>

<!-- Alert for urgent notifications -->
<div role="alert">
  <p>Form submission failed. Please check your email address.</p>
</div>

Forms and Input Accessibility

Forms are critical interaction points. Every input must be properly labeled, and error states must be communicated programmatically.

Labeling Inputs

<!-- Explicit label association (preferred) -->
<label for="email-address">Email Address</label>
<input type="email" id="email-address" name="email" required>

<!-- Implicit label (wrapping) -->
<label>
  Full Name
  <input type="text" name="full-name">
</label>

<!-- Input with no visible label, using aria-label -->
<input type="search" aria-label="Search products" placeholder="Search...">

<!-- Label for a group of related inputs -->
<fieldset>
  <legend>Preferred Contact Method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Error Handling and Validation

<!-- Accessible error message -->
<label for="username">Username</label>
<input type="text" id="username" name="username"
       aria-describedby="username-error username-requirements"
       aria-invalid="true"
       required>
<span id="username-error" role="alert">
  This username is already taken.
</span>
<span id="username-requirements">
  Username must be between 3 and 20 characters.
</span>

<!-- Form with accessible error summary -->
<form novalidate>
  <div role="alert" aria-live="assertive">
    <h2>Please correct the following errors:</h2>
    <ul>
      <li><a href="#email">Email address is required.</a></li>
      <li><a href="#password">Password must be at least 8 characters.</a></li>
    </ul>
  </div>
  <!-- Form fields follow -->
</form>

Images and Alternative Text

Alternative text conveys the meaning and purpose of images to users who cannot see them. The approach differs based on the image's role.

<!-- Informative image -->
<img src="team-photo.jpg" alt="Our engineering team at the 2024 conference">

<!-- Decorative image (empty alt, screen readers ignore it) -->
<img src="decorative-swirl.png" alt="">

<!-- Complex image with longer description -->
<img src="quarterly-earnings-chart.png"
     alt="Bar chart showing quarterly earnings: Q1 $2M, Q2 $3.5M, Q3 $4.1M, Q4 $5.2M"
     aria-describedby="chart-description">
<p id="chart-description">
  The chart illustrates a steady upward trend in quarterly earnings,
  with the most significant growth occurring between Q2 and Q3.
</p>

<!-- SVG with accessible title and description -->
<svg role="img" aria-labelledby="svg-title svg-desc">
  <title id="svg-title">Website traffic sources</title>
  <desc id="svg-desc">A pie chart showing 45% organic search,
  30% direct traffic, 15% social media, and 10% referral.</desc>
  <!-- SVG paths -->
</svg>

Accessible Data Tables

Tables require proper structural markup so screen readers can navigate rows, columns, and understand relationships between headers and data cells.

<table>
  <caption>
    Monthly Sales Revenue by Region (in thousands USD)
  </caption>
  <thead>
    <tr>
      <th scope="col">Region</th>
      <th scope="col">January</th>
      <th scope="col">February</th>
      <th scope="col">March</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">North America</th>
      <td>$120</td>
      <td>$145</td>
      <td>$160</td>
    </tr>
    <tr>
      <th scope="row">Europe</th>
      <td>$98</td>
      <td>$112</td>
      <td>$131</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <th scope="row">Total</th>
      <td>$218</td>
      <td>$257</td>
      <td>$291</td>
    </tr>
  </tfoot>
</table>

The scope attribute on <th> elements clarifies whether a header applies to a column (scope="col") or a row (scope="row"). For complex tables with multiple header levels, use id and headers attributes to explicitly map cells to their corresponding headers.

Keyboard Accessibility

Many users navigate entirely via keyboard. Every interactive element must be reachable and operable using the keyboard alone. Focus management ensures logical tab order and visible focus indicators.

Focusable Elements and Tab Order

<!-- Native interactive elements are focusable by default -->
<a href="/about">About Us</a>
<button type="button">Subscribe</button>
<input type="text">

<!-- Custom interactive element using tabindex -->
<div tabindex="0" role="button" aria-pressed="false">
  Custom Toggle Button
</div>

<!-- Managing tab order in a modal dialog -->
<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
  <h2 id="dialog-title">Confirm Deletion</h2>
  <button>Cancel</button>
  <button>Delete</button>
  <!-- Focus trap implementation needed here -->
</div>

<!-- Skip navigation link, first focusable element on the page -->
<a href="#main-content" class="skip-link">
  Skip to main content
</a>

Focus Management Patterns

<!-- Moving focus after a dynamic content change -->
<script>
  // After adding a new item to a list, move focus to it
  function addItemToList(itemText) {
    const list = document.getElementById('task-list');
    const newItem = document.createElement('li');
    newItem.innerHTML = `<button>${itemText}</button>`;
    list.appendChild(newItem);
    // Move focus to the new item's button
    newItem.querySelector('button').focus();
  }
</script>

Skip Navigation and Page Structure

A skip navigation link allows keyboard and screen reader users to bypass repetitive navigation and jump directly to the main content.

<!-- In your HTML, before the main navigation -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<nav aria-label="Primary navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/products">Products</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

<main id="main-content">
  <h1>Welcome to Our Store</h1>
</main>

<!-- CSS to visually hide skip link until focused -->
<style>
  .skip-link {
    position: absolute;
    left: -9999px;
    top: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 100;
  }
  .skip-link:focus {
    left: 10px;
    top: 10px;
  }
</style>

Accessible Interactive Components

Modal Dialogs

<!-- Accessible modal dialog -->
<div role="dialog"
     aria-labelledby="modal-heading"
     aria-describedby="modal-description"
     aria-modal="true"
     hidden>
  <h2 id="modal-heading">Delete Account</h2>
  <p id="modal-description">
    This action is permanent. All your data will be erased.
  </p>
  <button>Cancel</button>
  <button>Confirm Delete</button>
</div>

Dropdown Menu

<nav aria-label="User menu">
  <button aria-haspopup="true"
          aria-expanded="false"
          aria-controls="user-dropdown"
          id="user-menu-trigger">
    Account
  </button>
  <ul id="user-dropdown"
      role="menu"
      aria-labelledby="user-menu-trigger"
      hidden>
    <li role="menuitem">
      <a href="/profile">Profile</a>
    </li>
    <li role="menuitem">
      <a href="/settings">Settings</a>
    </li>
    <li role="menuitem">
      <a href="/logout">Log Out</a>
    </li>
  </ul>
</nav>

Tooltip

<button aria-describedby="tooltip-help">
  Help
</button>
<div id="tooltip-help" role="tooltip" hidden>
  Click here to access the help center and documentation.
</div>

Color Contrast and Visual Considerations

While primarily a CSS concern, color contrast requirements directly affect how you structure HTML and choose design tokens. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG AAA requires 7:1 and 4.5:1 respectively. Never convey information solely through color—always provide a secondary indicator such as text, pattern, or icon.

<!-- Bad: color alone indicates status -->
<span style="color: red;">Error</span>

<!-- Good: color plus icon and text -->
<span class="status-error">
  <span aria-hidden="true">⚠</span>
  Error: Email address is invalid
</span>

<!-- Required field indicator -->
<label for="name">
  Full Name
  <span aria-hidden="true" style="color: red;">*</span>
  <span class="visually-hidden">(required)</span>
</label>
<input id="name" required>

Screen-Reader-Only Content

Sometimes you need to provide information exclusively to screen reader users without affecting visual design. Use a visually hidden utility class rather than display: none or visibility: hidden, which also hide content from assistive technologies.

<style>
  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
  }
</style>

<!-- Usage example -->
<button>
  <span aria-hidden="true">★</span>
  <span class="sr-only">Add to favorites</span>
</button>

<!-- Pagination with screen reader context -->
<nav aria-label="Pagination">
  <a href="?page=2">
    Next
    <span class="sr-only">page</span>
  </a>
</nav>

Accessible Media and Animations

Video and Audio

<!-- Accessible video with captions -->
<video controls>
  <source src="tutorial.mp4" type="video/mp4">
  <track src="captions-en.vtt"
         kind="captions"
         srclang="en"
         label="English"
         default>
  <track src="captions-es.vtt"
         kind="captions"
         srclang="es"
         label="Spanish">
  <!-- Fallback for older browsers -->
  <p>Your browser does not support video playback.
     <a href="tutorial.mp4">Download the video</a> instead.</p>
</video>

<!-- Audio with transcript link -->
<audio controls>
  <source src="podcast-episode.mp3" type="audio/mpeg">
</audio>
<a href="transcript.html">Read the transcript</a>

Reduced Motion

<!-- Respect user's reduced motion preference -->
<style>
  @media (prefers-reduced-motion: reduce) {
    .animated-banner {
      animation: none;
    }
    * {
      animation-duration: 0.01ms !important;
      transition-duration: 0.01ms !important;
    }
  }
</style>

Testing HTML Accessibility

Testing is essential to verify that your accessible markup actually works as intended. Combine automated tools with manual testing for comprehensive coverage.

Automated Testing Tools

<!-- Integrate axe-core into your development workflow -->
<script>
  // Example: Running axe programmatically
  // Install: npm install axe-core
  import axe from 'axe-core';

  axe.run(document, {
    rules: {
      'color-contrast': { enabled: true },
      'aria-allowed-attr': { enabled: true }
    }
  }).then(results => {
    if (results.violations.length > 0) {
      console.table(results.violations);
    }
  });
</script>

Manual Testing Checklist

Use this checklist to systematically verify accessibility:

Best Practices Summary

Incorporate these principles into your daily development workflow:

Conclusion

HTML accessibility is a continuous practice rather than a one-time checklist. By grounding your markup in semantic elements, pairing every interactive control with appropriate labels and ARIA attributes when necessary, and testing with real assistive technologies, you create interfaces that work for everyone. The investment pays dividends: cleaner code, improved SEO, legal compliance, and most importantly, a web that includes rather than excludes. Start with the fundamentals outlined here, integrate accessibility checks into your development pipeline, and treat each component as an opportunity to practice inclusive design. Every accessible page you ship moves the web closer to its founding promise of being open to all.

🚀 Need a reliable AI agent for your project?

Deploy Hermes Agent in 10 minutes. Managed hosting, zero DevOps.

Get Started — $23.99/mo
← Back to all articles