Published Mar 15, 2026

Building accessible web apps that everyone can enjoy

Accessibility is not a feature — it is a fundamental aspect of quality software. Over one billion people worldwide have some form of disability, and many more have temporary or situational impairments. Building accessible apps is both the right thing to do and good for business.

Start with semantic HTML

The single most impactful thing you can do for accessibility is use the right HTML elements. A <button> is not a styled <div>. Semantic elements come with built-in keyboard handling, focus management, and screen reader support.

<!-- Bad: requires custom keyboard and ARIA handling -->
<div class="btn" onclick="submit()">Submit</div>

<!-- Good: works out of the box -->
<button type="submit">Submit</button>

Other semantic elements you should be using:

  • <nav> for navigation
  • <main> for primary content
  • <article> for self-contained content
  • <aside> for sidebars
  • <header> and <footer> for page sections
  • <h1> through <h6> in proper hierarchy

Keyboard navigation

Every interactive element must be reachable and operable via keyboard. This means:

  • All clickable elements should be focusable
  • Focus order should follow a logical reading order
  • Custom widgets should support expected keyboard patterns (arrows for menus, Escape to close modals)
  • Focus should never get trapped in a component

Test your app by putting your mouse away and navigating with only Tab, Shift+Tab, Enter, Space, and arrow keys.

ARIA: use it sparingly

ARIA (Accessible Rich Internet Applications) attributes provide additional context to assistive technologies. But the first rule of ARIA is: do not use ARIA if you can use a native HTML element instead.

When you do need ARIA:

<!-- Live regions for dynamic content -->
<div role="status" aria-live="polite">
  3 results found
</div>

<!-- Labels for icon buttons -->
<button aria-label="Close dialog">
  <svg>...</svg>
</button>

<!-- Describing relationships -->
<input aria-describedby="password-hint" type="password" />
<p id="password-hint">Must be at least 8 characters</p>

Color and contrast

  • Maintain a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text
  • Never use color as the only way to convey information
  • Test your design with a color blindness simulator

Testing for accessibility

  • axe DevTools — browser extension that catches common issues
  • Lighthouse — built into Chrome, includes an accessibility audit
  • Screen reader testing — VoiceOver on Mac, NVDA on Windows
  • Manual keyboard testing — the fastest way to find navigation issues

Start with the basics: semantic HTML, keyboard access, and sufficient contrast. These three things alone will catch the majority of accessibility issues.