Why I Build Every Website with Accessibility in Mind
Accessibility isn't a feature — it's a fundamental part of good web development. Here's how I approach it in every project.
One in five people in the UK has a disability. If your website isn't accessible, you're excluding 20% of your potential customers. Beyond the moral argument, it's simply bad business.
Accessibility doesn't have to be complicated or expensive. Most of it comes down to fundamentals: semantic HTML, proper heading hierarchy, sufficient colour contrast, keyboard navigation, and meaningful alt text for images.
I use Radix UI primitives (via shadcn/ui) for interactive components because they handle accessibility out of the box — proper ARIA attributes, keyboard interactions, focus management. Building these from scratch is error-prone and time-consuming.
Testing is crucial. I use a combination of automated tools (axe-core, Lighthouse) and manual testing with keyboard navigation and screen readers. Automated tools catch about 30% of accessibility issues; the rest requires human judgement.
For my clients, I frame accessibility as a competitive advantage. An accessible website reaches more people, performs better in search rankings (Google rewards accessible sites), and demonstrates that the business cares about all its customers. It's a win on every level.
Related Articles
How Tailwind CSS Completely Changed My Development Workflow
From skeptic to convert — why utility-first CSS made me faster, more consistent, and happier as a developer.
Vite vs Next.js: When I Use Each and Why
Both are excellent tools, but they solve different problems. Here's my practical guide to choosing the right one for your project.