A Complete Guide to Web Accessibility

Web accessibility means your site works for people with disabilities—including those who use screen readers, keyboard-only navigation, or need higher contrast and larger text. It also improves usability for everyone. This guide covers the fundamentals, practical techniques, and how to test and maintain an accessible site.

Why Accessibility Matters

Over a billion people worldwide have some form of disability. Many rely on assistive technology: screen readers, voice control, switch devices, or keyboard-only input. If your site isn't built with accessibility in mind, you're excluding a significant audience. Beyond ethics, accessible sites often rank better in search, have lower bounce rates, and are easier for all users to navigate.

In some jurisdictions, accessibility is a legal requirement. The Americans with Disabilities Act (ADA), the European Accessibility Act (EAA), and similar laws increasingly apply to websites. Building accessibly from the start is easier than retrofitting later.

Understanding WCAG

The Web Content Accessibility Guidelines (WCAG) are the international standard. WCAG 2.1 has three conformance levels: A (minimum), AA (common target), and AAA (highest). Most organizations aim for AA.

The Four Principles: POUR

WCAG is built around four principles, often summarized as POUR:

• Perceivable—Information and UI components must be presentable to users in ways they can perceive. Text alternatives for images, captions for video, content that can be presented in different ways (e.g., simpler layout) without losing meaning.
• Operable—UI components and navigation must be operable. Keyboard access, enough time to read and use content, no content that causes seizures, easy navigation and findability.
• Understandable—Information and operation must be understandable. Readable text, predictable behavior, input assistance (labels, error messages).
• Robust—Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. Valid markup, proper use of ARIA where needed.

Semantic HTML

Using the right HTML elements is the foundation of accessibility. Semantic elements convey meaning to browsers and assistive technologies.

Document Structure

Use <header>, <main>, <nav>, <footer>, <article>, and <section> to structure the page. One <main> per page. Headings (h1–h6) should form a logical outline—don't skip levels.

<header>
  <nav aria-label="Main navigation">...</nav>
</header>
<main id="main">
  <article>...</article>
</main>
<footer>...</footer>

Images and Media

Every meaningful image needs an alt attribute. Decorative images should have alt="" so screen readers skip them. For complex images (charts, diagrams), provide a longer description nearby or via aria-describedby. Video needs captions; audio needs transcripts.

<img src="chart.png" alt="Sales increased 20% in Q3" width="600" height="400">

Forms

Every form control needs a visible label. Use <label for="id"> or wrap the input. Group related fields with <fieldset> and <legend>. Provide clear error messages and associate them with the relevant field. Use required, aria-required, and aria-invalid where appropriate.

ARIA When Necessary

ARIA (Accessible Rich Internet Applications) supplements HTML when native semantics aren't enough. Use it sparingly—prefer semantic HTML first.

When to Use ARIA

• Custom widgets (tabs, accordions, modals) that don't have native equivalents
• Dynamic content that updates without a full page reload (live regions)
• Landmarks when HTML5 elements aren't sufficient

Common patterns: role="button" for clickable divs, aria-expanded for expandable sections, aria-live="polite" for announcements, aria-label when visible text isn't enough.

<button aria-expanded="false" aria-controls="menu" aria-haspopup="true">
  Menu
</button>
<ul id="menu" hidden>...</ul>

ARIA Pitfalls

Don't use ARIA when HTML already provides the semantics. Don't add role="button" to a <button>. Avoid aria-hidden on focusable elements—they become unreachable. Test with a screen reader; ARIA used incorrectly can make things worse.

Keyboard Navigation

All interactive elements must be reachable and operable via keyboard. Users should be able to tab through the page in a logical order. Focus indicators must be visible—don't remove outline without replacing it with a clear focus style.

• Use tabindex="0" to add custom elements to the tab order when needed
• Use tabindex="-1" for programmatic focus (e.g., after opening a modal)
• Never use tabindex greater than 0—it breaks the natural order

Modals and dropdowns need focus trapping and escape-key handling. When a modal opens, move focus inside it; when it closes, return focus to the trigger.

Color and Contrast

WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Use tools like WebAIM Contrast Checker or browser DevTools to verify. Don't rely on color alone to convey information—use icons, labels, or patterns as well.

Testing Your Site

Automated tools catch many issues but not all. Combine them with manual testing.

Automated Tools

• axe DevTools—Browser extension; integrates with Lighthouse
• Lighthouse—Built into Chrome DevTools; includes an accessibility audit
• WAVE—Web page evaluator; highlights issues visually

Manual Testing

Navigate your site using only the keyboard. Try a screen reader—NVDA (Windows) and VoiceOver (Mac) are free. Resize text, zoom the page, and test with high-contrast mode. Get feedback from users with disabilities when possible.

Getting Started

Start with the basics: semantic HTML, proper headings, alt text, and keyboard access. Run audits and fix critical issues first. Make accessibility part of your design and development process from the beginning, not an afterthought.