Building Accessible Websites

Web accessibility ensures that people with disabilities can perceive, understand, navigate, and interact with websites. It's not just a moral imperative — in many regions, it's a legal requirement. The good news is that accessible design often leads to better design for everyone.

Why Accessibility Matters

Over one billion people worldwide live with some form of disability. This includes visual, auditory, motor, and cognitive impairments. When you build an accessible website, you're not just helping a subset of users — you're improving the experience for everyone. Features like captions help in noisy environments, clear navigation helps on slow connections, and semantic HTML helps search engines understand your content.

Semantic HTML

The most impactful accessibility improvement you can make is using the right HTML element for the job:

<!-- Good: semantic button -->
<button type="submit">Sign Up</button>

<!-- Bad: div masquerading as a button -->
<div class="button" onclick="handleClick()">Sign Up</div>

<!-- Good: proper heading hierarchy -->
<h1>Page Title</h1>
<h2>Section Title</h2>
<h3>Subsection</h3>

<!-- Bad: using headings for styling -->
<h1 class="big-text">Section Title</h1>

<!-- Good: landmark regions -->
<nav aria-label="Main navigation">...</nav>
<main>...</main>
<aside>...</aside>
<footer>...</footer>

Semantic HTML provides built-in keyboard navigation, screen reader support, and search engine understanding. Never use a <div> or <span> in place of a semantic element.

ARIA Attributes

ARIA (Accessible Rich Internet Applications) attributes enhance semantics when HTML alone isn't enough:

<!-- Live region for dynamic content -->
<div role="status" aria-live="polite" id="notifications">
  3 new messages
</div>

<!-- Custom widget with proper roles -->
<div role="tablist" aria-label="Account settings">
  <button role="tab" aria-selected="true" aria-controls="panel-profile">Profile</button>
  <button role="tab" aria-selected="false" aria-controls="panel-security">Security</button>
</div>

<div id="panel-profile" role="tabpanel" hidden>Profile content</div>
<div id="panel-security" role="tabpanel" hidden>Security content</div>

<!-- Form validation -->
<input
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
  required
>
<span id="email-error" role="alert">Please enter a valid email address</span>

Use aria-label for unlabeled interactive elements, aria-describedby for additional context, and aria-live for dynamic content updates.

Every interactive element must be usable with a keyboard alone:

/* Visible focus indicators - never remove without replacement */
button:focus,
a:focus,
input:focus {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
}

/* Skip link for keyboard users */
.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
  background: #000;
  color: #fff;
  padding: 0.5rem 1rem;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

<a class="skip-link" href="#main-content">Skip to main content</a>

Testing Accessibility

Don't guess — test your work:

Lighthouse: Run the accessibility audit in Chrome DevTools
axe DevTools: Automated testing for common WCAG issues
Keyboard testing: Navigate your entire site using only Tab, Enter, and Escape
Screen reader testing: Try NVDA (free, Windows) or VoiceOver (built into macOS)
Color contrast: Use the WebAIM contrast checker to verify text readability

Conclusion

Accessibility is not a feature you add at the end — it's a design principle you apply from the start. Focus on semantic HTML first, then enhance with ARIA where needed, and always test with real assistive technologies. The WCAG 2.1 guidelines provide a comprehensive framework, but even implementing the basics — proper headings, alt text, keyboard navigation, and color contrast — makes a dramatic difference. Every website can be more accessible, and the effort required is often far less than you might expect.

Building Accessible Websites