Accessibility is quality engineering, not charity — semantic HTML, keyboard navigation, ARIA, and testing for WCAG-compliant React apps
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.
Write on Medium
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
Add alt text to all images (30 minutes for most sites)
Fix color contrast ratios (use a CSS find-and-replace for low-contrast grays)
Add a skip navigation link (5 minutes)
Ensure all form inputs have associated labels (15 minutes)
Set the lang attribute on the HTML element (1 minute)
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.
Originally published at https://www.thebeyondhorizon.com on July 22, 2025.
Top comments (0)