I built a sign-up form that looked beautiful. Responsive, modern, intuitive — at least to me. Then I watched a user with a screen reader try to use it. They got lost in the form structure. They couldn’t tell which field was required. They couldn’t navigate properly. What took me 30 seconds to fill out took them five minutes, and they gave up halfway through.

I realized something: I hadn’t built an intuitive form. I’d built a form that was intuitive to people who see the way I see. For everyone else, it was a mess.

That was my wake-up call. I started learning about accessibility. And I realized it’s not special treatment. It’s not “making things nicer for people with disabilities.” It’s about building products that actually work for everyone, regardless of how they perceive the world.

The Business Case for Accessibility

Web accessibility gets treated as a charity. It’s not. It’s money and legal risk.

About 25% of adults have a disability. Vision, hearing, mobility, cognitive. That’s a quarter of your potential users. You’re building a product that doesn’t work for a quarter of people. That’s not inclusive. That’s leaving money on the table.

There’s also the legal side. The ADA (Americans with Disabilities Act) applies online. The WCAG 2.1 standard is what courts reference. If your site doesn’t meet it and someone sues, you lose. The damages aren’t trivial. I’ve seen settlements in the millions.

Companies are getting sued for inaccessible websites. Not as charity suits. As real lawsuits with real damages. Target, Domino’s, Harvard University — companies bigger than most have had to pay up.

So: build accessible products because it’s the right thing to do, but also because it’s the smart business thing to do.

What Accessibility Actually Means

Accessibility is designing so that everyone can use your product, regardless of ability or circumstance. Not “add an accessible version.” Same product, everyone, same quality experience.

This includes:

Vision: People who are blind use screen readers. People with low vision need high contrast and large text. People with color blindness need more than color to distinguish information.

Hearing: People who are deaf need captions on videos. They need transcripts of audio content. They need visual indicators of sound (the phone’s ringing sound needs a visual alert).

Motor: People with limited mobility can’t use a mouse or small touch targets. They navigate with keyboards, eye trackers, voice commands.

Cognitive: People with dyslexia, ADHD, dementia need clear language, simple navigation, and consistent design. They get confused by unexplained jargon and complex layouts.

Temporary situations: You’ve got an arm in a cast — you can’t use a mouse. You’re in bright sunlight and can’t see your screen. You’re on a slow connection. You’re driving and can’t look at the screen. Accessibility helps everyone in difficult situations.

When accessibility is done right, it makes the product better for everyone. Better contrast helps people in bright sunlight. Keyboard navigation helps people without a mouse (or who prefer efficiency). Captions help people in noisy environments or where sound is off.

The WCAG Standard (Without the Jargon)

The Web Content Accessibility Guidelines (WCAG) 2.1 is the standard courts reference. It’s three levels:

Level A: Basic accessibility. Your images have alt text. Your colors aren’t the only way to convey information. You can navigate with keyboard.

Level AA: Enhanced accessibility. This is what companies usually target. Color contrast is 4.5:1. Form fields have labels. Videos have captions. Errors are explained clearly.

Level AAA: Maximum accessibility. Everything AA is, plus: color contrast is 7:1. Audio descriptions for videos. Enhanced language clarity. This is ambitious for new sites. Large corporations sometimes aim for this.

Most companies should aim for AA. It’s the legal standard and it catches 95% of issues.

How to Actually Make Your Site Accessible

Start with semantic HTML. Use `` for buttons, not `

`. Use `` with form fields. Use `` for images. Use heading hierarchy: `

` first, then `

`, never skip levels. This matters because screen readers and assistive tech rely on HTML structure.

Bad:

<div class="button" onclick="submitForm()">Submit</div>
<div class="input"></div>

Good:

<button type="submit">Submit</button>
<label for="email">Email</label>
<input id="email" type="email">

The difference is invisible to sighted users. But to a screen reader, the semantic version is a button that can be activated and a properly labeled form field. The div version is just text.

Use alt text for images. Describe what the image shows. Not “photo” or “image of desk.” “A developer reviewing code on a monitor.” For decorative images, use `alt=””` (empty alt) so screen readers skip it. For complex diagrams, include the data in text or a detailed alt text.

Test with keyboard navigation. Use Tab to move between elements. Shift+Tab to go backward. Try to complete a form without touching the mouse. If you can’t, it’s not keyboard accessible. Keyboard navigation is critical for motor disabilities, power users, and anyone in a pinch.

Check color contrast. The WCAG standard is 4.5:1 for normal text. Use a tool like WebAIM’s contrast checker to verify. Light gray text on white background? Fails. Dark text on colored background? Test it. This helps people with low vision and everyone in bright sunlight.

Make focus visible. When you Tab to an element, it should have a visible focus indicator. Not invisible. Not “you can see it if you squint.” A clear border or background change. This is critical for keyboard navigation.

Use ARIA carefully. ARIA (Accessible Rich Internet Applications) adds accessibility information to complex widgets. It’s powerful and easy to misuse. If you’re using a well-built component library, they already handle ARIA. If you’re building custom widgets, you might need it. But ARIA doesn’t fix inaccessible HTML. It supplements it.

Common Accessibility Mistakes

Thinking accessibility is about screen readers only. Screen readers are important, but they’re one piece. Keyboard navigation, color contrast, focus management, semantic HTML — these all matter independently.

Adding accessibility late. The worst time to add accessibility is at the end. It’s hardest and most expensive. Build accessibility from the start. Use semantic HTML. Check contrast while designing. Test keyboard nav while developing. It’s cheaper and faster than retrofitting.

Relying only on automated testing. Tools like axe, Lighthouse, and WAVE catch maybe 30% of issues. The rest require human testing. And the best testing is with actual people with disabilities, not engineers guessing. If you can, bring in accessibility consultants or hire testers who use assistive tech.

Making decorative elements focusable. If a div is decorative, don’t add tabindex. Users keyboard-navigating will tab to it and get confused. Keep keyboard navigation focused on interactive elements.

Using color alone to convey information. “Red fields are errors, green fields are valid.” What about colorblind users? Use text: “Error” or Valid. Use icons. Use color + something else.

Assuming accessibility is done once. It’s not. When you update your site, test accessibility again. When you change styles, check contrast again. Accessibility is continuous.

Tools That Actually Help

axe DevTools is a browser extension that finds accessibility issues. Lighthouse (in Chrome DevTools) checks accessibility along with performance. WAVE is another good tool.

But tools are just the start. Automated testing finds obvious issues. Real testing — with real people using assistive tech — finds the subtle ones.

for keyboard testing: just use your keyboard. Tab through the site. Can you access everything? Is focus visible? Are you ever trapped?

For screen reader testing: if you use Mac, try VoiceOver (built in). On Windows, NVDA is free. Spend an hour using the web with a screen reader. It’s eye-opening (or Ear-opening, technically).

When NOT to Punt on Accessibility

Some companies treat accessibility as “we’ll get to it later.” Later never comes. Or later is when you get sued.

If you’re a small startup with five engineers, you might not have dedicated accessibility time. But that doesn’t mean ignore it. Use semantic HTML. Test with a keyboard. Check contrast. These take an hour a week, not a month.

If you’re a public company or a company that handles sensitive data (health, finance, government), accessibility is non-negotiable. You’ll get sued if you don’t do it, and you should.

If you’re building something medical or safety-critical, accessibility is essential. This isn’t just legal. It’s ethical. People depend on this working.

FAQ

Is WCAG 2.1 the latest standard?

Yes. WCAG 2.1 is current (as of 2025). There’s a WCAG 3.0 in development, but 2.1 is the legal standard. Aim for AA compliance.

Do I need to support Internet Explorer?

No. IE is dead. Focus on modern browsers. Just don’t use new features without testing them in your target browsers.

Is accessible design ugly?

Do. Good accessible design is good design. High contrast helps readability. Clear labels help everyone. Keyboard navigation improves efficience. Accessible design is just good design.

What if accessibility conflicts with design?

Then design needs to change. If design doesn’t work for everyone, it’s not good design. This is a collaboration between design and engineering. Work it out together.

How much does accessibility cost?

If you build it in from the start, almost nothing. If you retrofit it, a lot. That’s why you build it in from the start.

Can I audit my site for accessibility?

Yes. Run axe or WAVE. Test keyboard navigation. Test with a screen reader. Check contrast. That gives you a baseline. Then hire an accessibility consultant for a more thorough review, or test with actual users with disabilities.

Accessibility is designing for reality, not an imaginary “default” user. One in four people have disabilities. Build for them. It’s legally required, morally right, and good business.

If you want to understand how accessibility fits into your larger product strategy and design system, check out our post on SEO for developers — accessibility and SEO go hand in hand.