Why I think about accessibility differently

Accessibility is often framed as a checklist. Add alt text, use semantic HTML, ensure colour contrast. Check, check, check.

That’s not wrong - those things matter. But for me, accessibility is something I feel before I think about it.

Living with hearing loss changes your defaults

I’ve been hard of hearing for as long as I can remember. That means I’ve spent years developing workarounds: reading lips, checking captions, asking people to repeat themselves, and quietly dreading phone calls.

When I started building for the web, these experiences became instincts. I don’t add captions to videos because a guidelines document told me to. I add them because I know exactly what it feels like to sit through a video that assumes everyone can hear perfectly.

What this looks like in practice

A few things I build for by default now:

Captions and transcripts. Every video. Not optional. Not “coming soon.”

No audio-only notifications. If your application uses a sound to signal an error, that error is invisible to me. Use visual feedback. Always.

Keyboard navigation. Not just because screen readers need it - because many people navigate without a mouse, for many different reasons.

Readable, clear copy. Dense jargon is hard for everyone. For people with cognitive differences, or who process information differently, it’s a barrier.

The real lesson

Accessibility stops feeling like extra work the moment you understand that you’re not designing for disabled users - you’re designing with the full range of human experience in mind.

Every constraint is a design prompt. Start there.