Building Accessible Web Applications: A Developer's Responsibility

The Reality of Web Accessibility

According to the World Health Organization, over 1.3 billion people — approximately 16% of the global population — live with some form of disability. Yet the WebAIM Million study (2024) found that 96.3% of home pages had detectable WCAG failures.

The most common errors:

1. Low contrast text (81% of pages)
2. Missing alt text for images (54%)
3. Missing form labels (48%)
4. Empty links (44%)
5. Missing document language (28%)

What Is WCAG?

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. The current version is WCAG 2.2 (published October 2023).

WCAG is organized around four principles — POUR:

Perceivable

Users must be able to perceive the information:

• Alt text on all meaningful images
• Captions on videos
• Sufficient color contrast (4.5:1 minimum)
• Content must be readable without color (don't use color as the only indicator)

Operable

Users must be able to operate the interface:

• Full keyboard navigation (Tab, Enter, Escape, Arrow keys)
• No keyboard traps (users can always move focus away)
• Skip navigation links for screen reader users
• Enough time to read and interact with content

Understandable

Users must be able to understand the content:

• Clear language (avoid jargon)
• Consistent navigation across pages
• Helpful error messages (not just "Invalid input")
• Labels on all form fields

Robust

Content must work with current and future technologies:

• Valid HTML — Proper semantic elements
• ARIA attributes where native HTML isn't sufficient
• Testing with real assistive technology

Practical Implementation

Semantic HTML First

<!-- ❌ Don't -->
<div onclick="navigate()">Click me</div>

<!-- ✅ Do -->
<button onclick="navigate()">Click me</button>

Native HTML elements have built-in accessibility: buttons are focusable, links are announced as links, headings create document structure.

ARIA — Use Sparingly

The first rule of ARIA is: don't use ARIA if you can use native HTML. ARIA should supplement, not replace, semantic markup.

Useful ARIA patterns:

• aria-label

  — Labels for icon-only buttons

• aria-expanded

  — Accordion/dropdown state

• aria-live

  — Dynamic content announcements

• role="alert"

  — Error messages

Focus Management

• Visible focus indicators (never

  outline: none

  without a replacement)
• Focus trapping in modals
• Return focus to trigger when closing dialogs

Testing Accessibility

Automated tools (catch ~30% of issues):

• axe DevTools (browser extension)
• Lighthouse accessibility audit
• WAVE (WebAIM's evaluation tool)

Manual testing (catches the rest):

• Tab through your entire page — can you reach and use everything?
• Use a screen reader (VoiceOver on Mac, NVDA on Windows)
• Zoom to 200% — does everything still work?
• Test with keyboard only — no mouse

The Legal Landscape

Web accessibility is legally mandated in many jurisdictions:

• ADA (USA) — Title III applies to websites (thousands of lawsuits annually)
• EAA (EU) — European Accessibility Act effective June 2025
• AODA (Canada) — Ontario's accessibility law
• Equality Act (UK) — Applies to digital services

In 2024, there were over 4,600 web accessibility lawsuits filed in the US alone (UsableNet).

The Business Case

Beyond legal compliance:

• 15% larger audience — Accessible sites serve more users
• Better SEO — Alt text, semantic HTML, and clear structure help search engines
• Improved UX for everyone — Captions help in noisy environments, contrast helps in sunlight, keyboard navigation helps power users

"The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect." — Tim Berners-Lee, inventor of the World Wide Web