Accessibility Isn't Optional (And It's Not That Hard)

The mindset shift

Accessibility often gets treated as an afterthought - something to check off before launch, or worse, something to add "when we have time." That approach is backwards.

Accessible design isn't a feature. It's a quality bar. Sites that are hard to use for people with disabilities are usually harder to use for everyone.

Who benefits

When you build accessibly, you help:

People with permanent disabilities. Visual impairments, motor difficulties, hearing loss, cognitive differences.

People with temporary issues. Broken arm, lost glasses, ear infection. Suddenly keyboard navigation or captions become essential.

People in challenging situations. Bright sunlight, noisy environment, one hand holding a coffee. Situational impairments happen to everyone.

People on different devices. Screen readers, voice control, keyboard-only navigation. Not everyone uses a mouse.

Accessible design is better design for everyone.

What I do on every project

Semantic HTML. Use the right elements: nav for navigation, main for main content, button for buttons. Screen readers understand semantic structure. Div soup is meaningless.

Keyboard navigation. Can you complete every action without a mouse? Tab through the page - does the focus order make sense? Can you activate buttons with Enter?

Colour contrast. Text needs to be readable. 4.5:1 contrast ratio for body text, 3:1 for large text. Tools like WebAIM's contrast checker make this easy to verify.

Alt text for images. Not "image123.jpg" - actually descriptive text. What does the image communicate? That's your alt text. For decorative images, use empty alt attributes.

Focus indicators. When you tab through a page, you should see where you are. Don't remove the focus outline without providing an alternative.

Form labels. Every input needs a label. Placeholder text doesn't count - it disappears when you start typing.

The quick wins

These changes take minutes and make meaningful differences:

Check your heading structure. Do you have one H1? Do headings nest properly (H2 inside H1 sections, H3 inside H2 sections)?

Make links descriptive. "Read the full case study" tells you where you're going. "Click here" doesn't.

Add skip links. Let keyboard users jump straight to the main content without tabbing through your entire navigation.

Test with keyboard only. Put away your mouse for five minutes. Can you use the site?

Tools that help

axe DevTools. Browser extension that catches common issues automatically.

Lighthouse accessibility audit. Built into Chrome DevTools. Quick automated check.

WAVE. Visual feedback showing accessibility issues directly on the page.

Screen reader testing. VoiceOver on Mac, NVDA on Windows. Try it occasionally - it's humbling and educational.

The library advantage

Good component libraries build accessibility in. I use shadcn/ui and Radix primitives - they handle ARIA attributes, keyboard interactions, and focus management properly.

Don't reinvent accessible components. Use libraries that've done the hard work. Your job is to use them correctly, not to implement ARIA from scratch.

The business case

If ethics don't convince you, consider:

Legal risk. Accessibility lawsuits are increasing. The ADA applies to websites.

SEO benefits. Accessible sites are easier for search engines to understand. Semantic HTML, descriptive links, and proper heading structure all help.

Larger audience. 15-20% of people have some form of disability. That's a significant portion of your potential users.

The bottom line

Accessibility isn't a separate checklist item. It's part of quality.

Build it in from the start. Use the right elements. Test with a keyboard. Check your contrast. The fundamentals take minimal extra effort but make your work usable by everyone.

That's the bar for professional web development.