Overview

I've seen countless developers struggle with accessibility—not because they don't care, but because they weren't taught the fundamentals early in their careers. This guide will give you the essential knowledge and practical tools to build inclusive web experiences from day one.

Why Accessibility Matters

Web accessibility (often abbreviated as “a11y“) ensures that people with disabilities can use your websites and applications. This isn't just about doing the right thing—it's about building better software for everyone. When you design for accessibility, you create experiences that work better for users with temporary injuries, situational limitations, and different devices. Consider this: the curb cuts on sidewalks were designed for wheelchair users, but they benefit everyone—people with strollers, delivery workers, travelers with luggage, and anyone who finds stairs challenging.

Core Principles: WCAG Guidelines

The Web Content Accessibility Guidelines (WCAG) are built on four key principles that form the foundation of accessible design:
Perceivable: Information must be presentable in ways users can perceive. This means providing text alternatives for images, captions for videos, and ensuring sufficient color contrast.
Operable: Interface components must be operable by all users. This includes keyboard navigation, giving users enough time to read content, and avoiding content that causes seizures.
Understandable: Information and UI operation must be understandable. Use clear language, make text readable, and ensure web pages appear and operate predictably.
Robust: Content must be robust enough to work with various assistive technologies. This means using semantic HTML and ensuring compatibility with screen readers.

Essential HTML Foundations

Semantic HTML is Your Friend

Using the right HTML elements for the right purpose is the easiest way to make your content accessible. Screen readers and other assistive technologies rely on semantic meaning to help users navigate.

 
<!-- Good: Semantic structure -->
<header>
  <nav>
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/contact">Contact</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h1>Article Title</h1>
    <p>Article content...</p>
  </article>
</main>

<!-- Avoid: Generic divs everywhere -->
<div class="header">
  <div class="nav">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
                    

Proper Heading Structure

Headings create a content outline that screen reader users rely on for navigation. Think of headings like a book's table of contents—they should be hierarchical and logical.

 
<!-- Good: Logical heading structure -->
<h1>Main Page Title</h1>
  <h2>Section Title</h2>
    <h3>Subsection Title</h3>
    <h3>Another Subsection</h3>
  <h2>Another Section</h2>

<!-- Avoid: Skipping heading levels -->
<h1>Main Title</h1>
<h4>This skips h2 and h3</h4>
                    

Meaningful Link Text

Link text should make sense when read out of context. Screen reader users often navigate by jumping between links, so “click here“ doesn't provide useful information.

 
<!-- Good: Descriptive link text -->
<a href="/pricing">View our pricing plans</a>
<a href="/report.pdf">Download the annual report (PDF, 2.1MB)</a>

<!-- Avoid: Generic link text -->
<a href="/pricing">Click here</a>
<a href="/report.pdf">Read more</a>
                    

Form Accessibility

Forms are critical interaction points that must work for everyone. Here are the essential practices:

Always Use Labels

Every form input needs a label that's programmatically associated with it. This helps screen readers announce what each field is for.

 
 <!-- Good: Explicit labels -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required>

<!-- Also good: Implicit labels -->
<label>
  Email Address
  <input type="email" name="email" required>
</label>

<!-- Avoid: Placeholder as label -->
<input type="email" placeholder="Email Address" name="email">
                    

Error Handling and Validation

When forms have errors, users need clear information about what went wrong and how to fix it.

 
<label for="password">Password</label>
<input 
  type="password" 
  id="password" 
  name="password" 
  aria-describedby="password-error"
  aria-invalid="true"
  required
>
<div id="password-error" role="alert">
  Password must be at least 8 characters long
</div>
                    

Fieldsets and Legends

Group related form fields using fieldsets and provide clear legends, especially for radio buttons and checkboxes

 
<fieldset>
  <legend>Preferred contact method</legend>
  <label>
    <input type="radio" name="contact" value="email">
    Email
  </label>
  <label>
    <input type="radio" name="contact" value="phone">
    Phone
  </label>
</fieldset>
                    

Images and Media

Alt Text Best Practices

Alt text serves different purposes depending on the image's role in your content.

 
<!-- Informative image -->
<img src="sales-chart.png" alt="Sales increased 25% from January to March 2024">

<!-- Decorative image -->
<img src="decorative-border.png" alt="" role="presentation">

<!-- Functional image (like a button) -->
<img src="search-icon.png" alt="Search">

<!-- Complex image -->
<img src="complex-chart.png" alt="Quarterly revenue breakdown" longdesc="revenue-description.html">
                    

Video and Audio Content

Multimedia content needs alternatives for users who can't see or hear it.

 
<video controls>
  <source src="presentation.mp4" type="video/mp4">
  <track kind="captions" src="captions.vtt" srclang="en" label="English">
  <track kind="descriptions" src="descriptions.vtt" srclang="en" label="Audio descriptions">
  <p>Your browser doesn't support video. <a href="presentation.mp4">Download the video</a></p>
</video>
                    

Keyboard Navigation

Many users navigate websites using only their keyboard. Your interfaces must be fully keyboard accessible.

Focus Management

Ensure all interactive elements can receive focus and that focus is visible.

 
/* Good: Visible focus indicators */
button:focus,
a:focus,
input:focus {
  outline: 2px solid #007acc;
  outline-offset: 2px;
}

/* Avoid: Removing focus indicators */
button:focus {
  outline: none; /* Don't do this without providing an alternative */
}
                    

Skip Links

Provide a way for keyboard users to skip repetitive content.

 
<a href="#main-content" class="skip-link">Skip to main content</a>
<nav>
  <!-- Navigation items -->
</nav>
<main id="main-content">
  <!-- Main content -->
</main>

// CSS
.skip-link {
  position: absolute;
  top: -40px;
  left: 6px;
  background: #000;
  color: #fff;
  padding: 8px;
  text-decoration: none;
  transition: top 0.3s;
}

.skip-link:focus {
  top: 6px;
}
                    

ARIA: When and How to Use It

ARIA (Accessible Rich Internet Applications) attributes provide additional semantic information when HTML alone isn't sufficient. Remember: the first rule of ARIA is don't use ARIA if you can use semantic HTML instead.

 
<!-- Button that controls a dropdown -->
<button 
  aria-expanded="false" 
  aria-haspopup="menu" 
  aria-controls="dropdown-menu"
>
  Menu
</button>
<ul id="dropdown-menu" hidden>
  <li><a href="/profile">Profile</a></li>
  <li><a href="/settings">Settings</a></li>
</ul>

<!-- Live region for dynamic content -->
<div aria-live="polite" id="status-message"></div>

<!-- Tab interface -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button>
</div>
<div id="panel1" role="tabpanel">Content for tab 1</div>
<div id="panel2" role="tabpanel" hidden>Content for tab 2</div>

Color and Contrast

Visual design plays a crucial role in accessibility. Ensure sufficient contrast between text and background colors.

Contrast Requirements:

• Normal text: 4.5:1 contrast ratio minimum
• Large text (18pt+ or 14pt+ bold): 3:1 contrast ratio minimum
• Non-text elements (icons, buttons): 3:1 contrast ratio minimum

Don't Rely on Color Alone

Information shouldn't be conveyed through color alone. Always provide additional indicators.

 
<!-- Good: Color plus icon -->
<span class="error">
  <svg aria-hidden="true" focusable="false">
    <use xlink:href="#error-icon"></use>
  </svg>
  Please fix the errors below
</span>

<!-- Avoid: Color only -->
<span style="color: red;">Please fix the errors below</span>

Mobile Accessibility

Mobile accessibility is crucial as more users access the web through mobile devices.

Touch Targets

Ensure interactive elements are large enough for easy tapping.

 
/* Minimum 44px touch target */
button, 
a, 
input[type="checkbox"], 
input[type="radio"] {
  min-height: 44px;
  min-width: 44px;
}

Viewport and Zoom

Allow users to zoom up to 200% without horizontal scrolling.

 
<meta name="viewport" content="width=device-width, initial-scale=1.0">

Testing Your Work with Axe

The axe browser extension is an indispensable tool for catching accessibility issues during development. It's created by Deque Systems and provides automated testing right in your browser's developer tools.

Installing and Using Axe browser extension

• Install the axe DevTools extension for your browser (Chrome, Firefox, or Edge)
• Open your website and press F12 to open developer tools
• Look for the "axe DevTools" tab
• Click "Scan ALL of my page" to run a full accessibility audit

Understanding Axe Results

Axe categorizes issues by severity:
Critical: Issues that will definitely block users with disabilities.
Serious: Issues that may block users or make tasks very difficult.
Moderate: Issues that make tasks more difficult but don't block users.
Minor: Issues that slightly inconvenience users.

Making Axe Part of Your Workflow

Don't wait until the end of development to test accessibility. Run axe scans regularly

• After implementing new features
• Before pushing code to production
• During code reviews
• When debugging user-reported issues

Axe also provides detailed guidance on fixing each issue, including code examples and links to WCAG guidelines.

Building Accessibility into Your Process

Start with Accessibility in Mind

Don't treat accessibility as an afterthought. Consider it during:

• Design reviews
• User story creation
• Code reviews
• Testing phases

Common Mistakes to Avoid

• Using placeholder text as labels: Screen readers might not announce placeholders consistently
• Removing focus indicators: Always provide visible focus states
• Creating keyboard traps: Ensure users can navigate away from all interactive elements
• Overusing ARIA: Use semantic HTML first, ARIA only when necessary
• Ignoring error states: Provide clear, helpful error messages

Resources for Continued Learning

• WebAIM: Comprehensive accessibility resources and testing tools
• A11y Project: Community-driven accessibility checklist and resources
• WCAG Quick Reference: Official guidelines with practical examples
• Inclusive Design Principles: Official guide to inclusive design

Conclusion

Web accessibility isn't just about compliance—it's about creating inclusive experiences that work for everyone. By following semantic HTML practices, testing with tools like axe, and keeping accessibility in mind throughout your development process, you'll build better websites that serve all users. Remember, accessibility is a journey, not a destination. Start with the basics covered in this guide, use automated testing tools like axe to catch issues early, and continue learning as you grow in your career. Your future self—and your users—will thank you for building this foundation now. The web is for everyone. Let's make sure it works for everyone too.