Web Development22 July 2025·9 min read

Web Accessibility in React: A Practical WCAG 2.1 Guide

Accessibility is quality engineering, not charity. A practical guide to WCAG compliance in React applications — semantic HTML, keyboard navigation, ARIA, and testing.

AccessibilityWCAGA11yReactSemantic HTMLScreen Readers

Why Accessibility Is a Business Requirement

Web accessibility is not charity work — it is engineering quality. An accessible website works better for everyone: keyboard users, screen reader users, users with slow connections, users on old devices, and users in bright sunlight who cannot see low-contrast text.

In India, an estimated 26.8 million people have visual impairments. Globally, 15% of the population lives with some form of disability. If your website is inaccessible, you are excluding a significant portion of potential customers.

Beyond ethics and market reach, accessibility impacts SEO. Google's crawlers are essentially blind users — they rely on semantic HTML, alt text, and document structure to understand your content. An accessible website is inherently more SEO-friendly.

The WCAG 2.1 Framework

The Web Content Accessibility Guidelines (WCAG) organize requirements under four principles, known as POUR:

Perceivable

Users must be able to perceive the content through at least one sense.

Alt text for images: Every informational image needs descriptive alt text. Decorative images get alt="" (empty alt attribute, not missing alt attribute).

Color contrast: Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Use the WebAIM Contrast Checker to verify.

Captions for video: Pre-recorded video content needs synchronized captions. Live video needs captions where feasible.

Do not rely on color alone: "Click the red button" is meaningless to colorblind users. Use color plus text, icons, or patterns.

Operable

Users must be able to operate the interface.

Keyboard navigation: Every interactive element must be reachable and operable with keyboard alone. Tab to navigate, Enter to activate, Escape to close.

Focus indicators: The currently focused element must have a visible outline. Never remove the default focus ring without adding a custom one.

Skip navigation link: A hidden link that becomes visible on focus, allowing keyboard users to skip the header and navigation to reach main content directly.

No keyboard traps: Users must be able to Tab into and out of every component. Modal dialogs must trap focus while open and return focus when closed.

Understandable

Users must be able to understand the content and interface.

Language attribute: Set lang="en" (or appropriate language) on the HTML element. Screen readers use this to select the correct pronunciation engine.

Error identification: Form validation errors must identify which field has the error and describe how to fix it. "Invalid input" is not helpful. "Email address must include @" is.

Consistent navigation: Navigation should appear in the same location and order across all pages.

Robust

Content must work with current and future technologies.

Valid HTML: Proper heading hierarchy (h1 → h2 → h3, never skipping levels). Correct use of semantic elements (nav, main, footer, article, section).

ARIA when needed: Use ARIA attributes only when native HTML elements cannot express the semantics. A button element is better than a div with role="button".

Implementing Accessibility in React

Use Semantic HTML

The biggest accessibility win costs zero effort. Use the right HTML elements:

button for clickable actions (not div with onClick)

a for navigation links

nav for navigation sections

main for primary content

form with proper label associations

ul/ol for lists

Component Libraries That Care

Radix UI and Headless UI provide unstyled, fully accessible components for complex patterns like dropdown menus, dialogs, tabs, and popovers. They handle ARIA attributes, keyboard navigation, and focus management correctly. We use Radix UI as the foundation for all our component systems.

Testing Accessibility

axe DevTools: Browser extension that scans the current page for WCAG violations. Run it on every page during development.

Lighthouse accessibility score: Automated audit included in Chrome DevTools. Aim for 90+ (100 is achievable for most sites).

Screen reader testing: Test with NVDA (Windows, free) or VoiceOver (macOS, built-in). Automated tools catch 30-40% of accessibility issues — the rest requires manual testing.

Keyboard testing: Unplug your mouse and navigate your site. If you get stuck or cannot access a feature, keyboard users cannot either.

Quick Wins for Existing Sites

1. Add alt text to all images (30 minutes for most sites)

2. Fix color contrast ratios (use a CSS find-and-replace for low-contrast grays)

3. Add a skip navigation link (5 minutes)

4. Ensure all form inputs have associated labels (15 minutes)

5. Set the lang attribute on the HTML element (1 minute)

6. Test and fix keyboard navigation for interactive components (1-2 hours)

These six changes address the majority of accessibility issues on most websites.

Accessibility is not a feature — it is quality engineering. Want us to audit your site? Contact us.

The Beyond Horizon Team

We are a digital agency based in Ajmer, India, specializing in Next.js web applications, React Native mobile apps, and UI/UX design. 150+ projects delivered.

About Us →

Web Development