Building Accessible Web Applications: A Developer's Guide

Web accessibility (often abbreviated as a11y) is about making your web applications usable by everyone, including people with disabilities. It's not just the right thing to do—it's often legally required and expands your potential user base.

Why Accessibility Matters

• 1 billion people worldwide have some form of disability
• Accessible design benefits everyone (clear navigation, readable text, keyboard support)
• Legal requirements (ADA, Section 508, WCAG guidelines)
• Better SEO (semantic HTML helps search engines)
• Improved user experience for all users

Key Principles (POUR)

The Web Content Accessibility Guidelines (WCAG) are built on four principles:

1. Perceivable: Information must be presentable to users in ways they can perceive
2. Operable: Interface components must be operable by all users
3. Understandable: Information and operation must be understandable
4. Robust: Content must be robust enough to work with various technologies

Essential Accessibility Practices

1. Semantic HTML

Use appropriate HTML elements for their intended purpose:

<!-- Good: Semantic HTML -->
<nav>
  <ul>
    <li><a href="/home">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

<!-- Bad: Non-semantic divs -->
<div class="nav">
  <div onclick="navigate()">Home</div>
  <div onclick="navigate()">About</div>
</div>

2. Keyboard Navigation

Ensure all interactive elements are keyboard accessible:

// Good: Proper button element
<button onClick={handleClick}>Submit</button>

// Bad: Div as button (not keyboard accessible by default)
<div onClick={handleClick}>Submit</div>

Test your site using only a keyboard:

• Tab to navigate forward
• Shift + Tab to navigate backward
• Enter or Space to activate elements

3. ARIA Labels

Use ARIA (Accessible Rich Internet Applications) attributes when HTML semantics aren't enough:

<button
  aria-label="Close dialog"
  onClick={closeDialog}
>
  ×
</button>

<input
  type="search"
  aria-label="Search articles"
  placeholder="Search..."
/>

4. Color Contrast

Ensure sufficient color contrast for text readability:

• Normal text: Minimum 4.5:1 contrast ratio
• Large text (18pt+): Minimum 3:1 contrast ratio

Use tools like WebAIM's Contrast Checker to verify your color choices.

5. Alternative Text for Images

Always provide descriptive alt text:

<!-- Informative image -->
<img
  src="chart.png"
  alt="Bar chart showing 50% increase in sales in Q1 2024"
/>

<!-- Decorative image -->
<img
  src="decoration.png"
  alt=""
  role="presentation"
/>

6. Form Accessibility

Make forms accessible with proper labels and error handling:

<form>
  <label htmlFor="email">
    Email Address
    <span aria-label="required">*</span>
  </label>
  <input id="email" type="email" required aria-describedby="email-error" />
  <span id="email-error" role="alert">
    {emailError}
  </span>
</form>

7. Focus Management

Manage focus appropriately, especially in dynamic content:

function Modal({ isOpen, onClose, children }) {
  const modalRef = useRef();

  useEffect(() => {
    if (isOpen) {
      // Trap focus inside modal
      modalRef.current?.focus();
    }
  }, [isOpen]);

  return (
    <div ref={modalRef} role="dialog" aria-modal="true" tabIndex={-1}>
      {children}
    </div>
  );
}

Testing for Accessibility

Automated Testing Tools

• Lighthouse: Built into Chrome DevTools
• axe DevTools: Browser extension for accessibility testing
• WAVE: Web accessibility evaluation tool
• Pa11y: Automated accessibility testing in CI/CD

Manual Testing

Automated tools catch only ~30-40% of accessibility issues. Always:

1. Navigate with keyboard only
2. Use a screen reader (NVDA, JAWS, VoiceOver)
3. Test with browser zoom at 200%
4. Check color contrast
5. Test with images and CSS disabled

Common Mistakes to Avoid

1. ❌ Using div or span for clickable elements instead of button or a
2. ❌ Missing or generic alt text ("image.jpg")
3. ❌ Poor color contrast
4. ❌ Keyboard traps (unable to tab out of element)
5. ❌ Missing form labels
6. ❌ Inaccessible modals and dropdowns
7. ❌ Auto-playing media without controls

Resources

• WCAG 2.1 Guidelines
• MDN Web Accessibility
• WebAIM
• A11y Project
• Inclusive Components by Heydon Pickering

Conclusion

Building accessible web applications isn't just about compliance—it's about creating better experiences for everyone. Start with semantic HTML, test with keyboard and screen readers, and make accessibility a core part of your development process, not an afterthought.

Remember: Accessibility is not a feature. It's a requirement.

What accessibility practices do you follow in your projects? I'd love to hear your thoughts!