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

In early 2025, I got diagnosed with hearing loss and got hearing aids for the first time. Before the official diagnosis, I’ve started developing workarounds: reading lips, checking captions, asking people to repeat themselves, and quietly dreading soft spoken people (who would’ve figured that can become something to get uncomfortable with).

Nowadays, I’ve accepted my new situation and 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.