Accessibility Isn't Optional: Building for Everyone

26% of adults in the United States have some type of disability. That's one in four people. Visual impairments, motor limitations, hearing loss, cognitive differences — these aren't edge cases. They're a quarter of your potential user base.

And yet, a 2024 analysis of the top million websites found that 96% had detectable accessibility failures. Not subtle issues — failures. Buttons without labels. Images without alt text. Forms that can't be navigated with a keyboard. Color contrast so low that text is unreadable for anyone with impaired vision.

Accessibility isn't a premium feature. It isn't a nice-to-have for the next sprint. It's a baseline requirement that most of the industry fails at — and fixing it isn't as hard as most developers think.

What Accessibility Means in Practice

Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with your application. The Web Content Accessibility Guidelines (WCAG) define four principles:

Perceivable: Users can see or hear the content. Images have alt text. Videos have captions. Text has sufficient contrast.

Operable: Users can navigate and interact. Everything works with a keyboard. Nothing requires precise mouse movements. Nothing flashes in seizure-inducing patterns.

Understandable: Content and behavior are predictable. Labels are clear. Error messages explain what went wrong. Navigation is consistent.

Robust: Content works across assistive technologies. Semantic HTML is used correctly. ARIA attributes are applied properly. The application works with screen readers, magnifiers, and voice control.

The Five Changes That Fix Most Problems

You don't need to become an accessibility expert to dramatically improve your application. Five changes address the majority of common failures.

1. Use Semantic HTML

The single most impactful thing you can do. Semantic HTML elements (<button>, <nav>, <main>, <header>, <form>, <label>) carry meaning that assistive technologies understand. A <div> with an onClick handler looks like a button to sighted users but is invisible to screen readers.

<!-- Bad: looks like a button, doesn't behave like one for assistive tech -->
<div class="btn" onclick="submit()">Submit</div>

<!-- Good: is a button, behaves like one for everyone -->
<button type="submit">Submit</button>

The <button> element is focusable (keyboard users can reach it), has an implicit role (screen readers announce "button"), responds to Enter and Space keys, and communicates its purpose. The <div> does none of this without significant additional work.

Use the right element. <a> for navigation, <button> for actions, <input> for form fields, <table> for tabular data, <h1>-<h6> for headings in hierarchy. Every time you use a <div> or <span> for interactive content, ask: "Is there a semantic element that does this?"

2. Add Alt Text to Images

Every image needs a text alternative. Screen readers announce images by their alt text. Without it, users hear "image" with no context.

<!-- Bad: no information for screen readers -->
<img src="chart.png">

<!-- Good: describes the content -->
<img src="chart.png" alt="Bar chart showing revenue growth from $50K in January to $120K in June">

<!-- Decorative images: empty alt to skip them -->
<img src="decorative-border.png" alt="">

Content images need alt text that describes what the image communicates. "Photo of a woman" is less useful than "Customer service representative helping a client on a video call."

Decorative images (borders, spacers, backgrounds) should have alt="" so screen readers skip them entirely. An image that adds no information shouldn't create noise.

3. Ensure Keyboard Navigation

Every interactive element must be reachable and operable with a keyboard. Tab to navigate. Enter or Space to activate. Escape to close dialogs.

Test this: put your mouse aside and try to use your application with only a keyboard. Can you:

• Tab through all interactive elements in a logical order?

• See which element is focused (visible focus indicator)?

• Activate buttons and links with Enter?

• Navigate form fields and select options?

• Close dialogs and menus with Escape?

If any of these fail, keyboard users — and by extension, screen reader users — can't use your application.

The biggest offenders: Custom dropdowns that don't support arrow keys. Modal dialogs that don't trap focus (Tab escapes the dialog into the page behind it). Infinite scroll that loads content but doesn't make it keyboard-accessible.

4. Fix Color Contrast

WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Light gray text on a white background fails. So does most light text on light backgrounds and dark text on dark backgrounds.

Use a contrast checker. Chrome DevTools highlights contrast issues. The WebAIM contrast checker lets you test specific color combinations. Your design tool (Figma, Sketch) likely has a contrast plugin.

Don't rely on color alone. If a form field turns red for errors, also add an error message. If a status indicator uses green/yellow/red, also add text or icons. Color-blind users (8% of males) cannot distinguish the colors.

5. Label Your Form Fields

Every form input needs a visible label connected to the input. Placeholder text is not a label — it disappears when the user starts typing, leaving them with no context.

<!-- Bad: placeholder disappears, screen reader has no label -->
<input type="email" placeholder="Email address">

<!-- Good: visible label, connected to input -->
<label for="email">Email address</label>
<input type="email" id="email">

The for attribute on <label> connects it to the id on the <input>. Screen readers announce "Email address, edit text" when the field is focused. Without the label, they announce "edit text" — and the user has no idea what to type.

Testing Accessibility

Automated Testing

Run an automated scanner first. It catches the easy stuff.

• axe DevTools (browser extension): Scans the current page and reports WCAG violations.

• Lighthouse (Chrome DevTools): Includes an accessibility audit.

• eslint-plugin-jsx-a11y: Catches accessibility issues in React code during development.

Automated tools catch about 30% of accessibility issues — mostly structural problems like missing alt text, unlabeled inputs, and contrast failures. They can't catch logical issues like tab order that makes no sense or alt text that doesn't actually describe the image.

Manual Testing

The other 70% requires human testing.

• Keyboard-only navigation: Can you complete every task without a mouse?

• Screen reader testing: Turn on VoiceOver (Mac), NVDA (Windows), or TalkBack (Android) and try to use your application. This is eye-opening.

• Zoom to 200%: Does the layout hold? Can you still read and interact with everything?

User Testing

Include people with disabilities in your user testing. Automated and manual testing catches technical violations. Users with disabilities find the real usability problems — the patterns that technically pass WCAG but are still difficult to use.

The Business and Legal Case

Beyond doing the right thing:

Legal requirements are real. The ADA in the US, the EAA in the EU, and similar laws worldwide require accessible digital services. Lawsuits over inaccessible websites have increased dramatically — over 4,000 in 2023 alone in the US.

Market size is significant. People with disabilities have $490 billion in disposable income in the US alone. Inaccessible products exclude them and their purchasing power.

Accessibility improves usability for everyone. Captions help people in noisy environments. Keyboard navigation helps power users. Clear contrast helps everyone in bright sunlight. Good form labels help everyone fill out forms faster.

Key Takeaway

Accessibility isn't optional — it's a baseline requirement that 96% of websites fail. Five changes fix most issues: semantic HTML, alt text, keyboard navigation, color contrast, and labeled form fields. Test with automated tools (catches 30%) and manual keyboard/screen reader testing (catches the rest). The work isn't hard. The excuse of not knowing how no longer holds — the standards are clear, the tools are free, and the impact is real.