You don’t need to be an accessibility expert to make your website more inclusive; you just need to start.
I’ll be honest with you: I used to think web accessibility was something you could “tack on” at the end of a project. Maybe you’ve felt the same way, like it’s another checklist item to satisfy a client requirement or avoid a lawsuit.
Then I watched a screen reader user try to navigate a site I’d built. In under two minutes, they encountered three blockers that my automated testing tools had completely missed. That experience changed how I think about the web.
Let’s talk about what actually makes a website accessible, not as a compliance burden, but as a practice of building better experiences for everyone.
The Foundation: Semantic HTML
Here’s the thing about accessible code: browsers and assistive technologies already know how to handle proper HTML. When you use a <button>, screen readers announce it as a button. When you use <nav>, they know it’s navigation. That’s free accessibility baked into the platform.
I want you to do this today: Check your code for <div> or <span> elements that have click handlers attached. If it’s clickable, it should probably be a <button> or <a> tag. And that heading structure? Your <h1> should be the page’s main topic, with <h2>s as subtopics, and so on. Skip a level, and you’ve effectively created a “4th floor” without a 3rd floor for someone navigating with a screen reader.
Images and Media: The Visual Isn’t Universal
You’ve heard about alt text. But here’s what I wish someone had told me earlier: good alt text is contextual. If you’re writing about a photo of a dog on a beach, the alt text should serve the content. Is the article about dog training? “Golden retriever learning to stay on a busy beach.” Is it about travel photography? “Beach scene at sunset with a golden retriever running through surf.”
For decorative images, those spacer GIFs or purely visual flourishes – alt="" tells screen readers to skip it. That’s exactly what you want.
For video and audio? Provide captions, transcripts, or at minimum, a summary of what’s happening. Not everyone can hear, and not everyone can see, but everyone should get the full experience.
Keyboard Navigation: Not Everyone Uses a Mouse
Here’s a quick reality check: People with motor disabilities, temporary injuries (like a broken arm), or even power users who prefer keyboard shortcuts all navigate the web without a mouse. If your site can’t be used with a keyboard, you’re excluding a significant portion of your audience.
Run this test right now: close your browser tab, open it again, and navigate using only the Tab, Enter, and Space keys. Can you reach every interactive element? Can you see a clear focus indicator (that blue outline or custom highlight showing where you are)?
Please don’t remove the default :focus outline unless you’ve replaced it with something more visible. That’s not a design improvement; it’s a navigation hazard.
Colour and Contrast: Beyond Visual Appeal
This one caught me off guard early in my career. I designed a beautiful error message with subtle red text clean, minimal, perfect. Then I learned that some users couldn’t see the colour difference at all, and others couldn’t read it because the contrast was too low.
The WCAG AA standard for normal text contrast is 4.5:1. You can check this with browser dev tools or tools like Contrast Checker.
More importantly: never convey meaning with colour alone. If an error state is red, also show an icon or descriptive text. If required fields are marked in red, add an asterisk or the word “(required)”. Colour is an enhancement, not the message itself.
Forms: Where Accessibility Breaks Down Most Often
Forms are the most common point of failure I see. People want to sign up, buy something, or contact you, and if they can’t complete the form, you’ve lost both a user and a customer.
Here’s the simple rule: every input needs a visible, associated <label>. Placeholder text isn’t a label; it disappears when you start typing, and that’s a problem for users with memory or cognitive issues.
And error messages? Please link them to the relevant field with aria-describedby. When a form says “Please fix the highlighted fields,” a screen reader user might not know which field is actually highlighted. Link the error message to the input so the error gets read aloud automatically.
Testing: Automation Only Gets You So Far
Here’s a truth that might save you hours of false confidence: automated testing tools like Lighthouse and axe DevTools catch about 30-40% of real accessibility issues. They’re excellent for catching low-hanging fruit: missing alt text, colour contrast, semantic HTML issues. But they’ll never find a confusing interaction flow, a weird screen reader announcement, or a keyboard trap.
The only way to truly test accessibility is with people who use assistive technologies.
If you can’t do that (and most of us can’t), at least spend an hour testing with a screen reader yourself:
- VoiceOver is built into macOS and iOS
- NVDA is a free screen reader for Windows
- TalkBack is Android’s built-in screen reader
Or even simpler: test with the tools you already have. Turn on your browser’s device emulation, disable CSS, or try navigating with just your keyboard. You’ll find issues you never knew existed.
The Bigger Picture
Here’s the thing about accessibility: it’s not just about disabilities. It’s about building a web that works for everyone on mobile phones, in bright sunlight, with noisy surroundings, with ageing eyes, with temporary injuries, with different native languages.
When we build accessible websites, we build better websites. They’re faster, easier to maintain, more SEO-friendly, and they work for the widest possible audience.
The checklist I’ve shared is a starting point. But remember: accessibility isn’t a single sprint; it’s a practice, a mindset, a commitment to building a web that truly includes everyone.
So here’s my challenge to you: Pick one thing from this checklist and implement it today. Not a huge overhaul, just one small win. Then another tomorrow, and another the day after.
Your users will notice. And you’ll notice your craft improving too.
What’s the biggest accessibility challenge you’ve faced in your own work? I’d love to hear your experiences in the comments: the good, the bad, and the lessons learned along the way.
