Why Accessibility Isn’t Just a Buzzword
Pull up a chair, friend. Let’s talk about something that’s been close to my heart—and often under the radar in front-end dev circles: HTML accessibility. I’ve been down this road more times than I care to count, fumbling with ARIA roles or forgetting alt tags in the rush to ship. But here’s the deal: getting accessibility right isn’t about ticking boxes or adding fluff. It’s about real people, real lives, and making sure nobody gets left behind just because they use a screen reader, keyboard, or have color blindness.
So, in this post, I’m walking you through some common HTML accessibility mistakes I’ve stumbled over (and fixed), plus how you can sidestep them. Think of it as a friendly nudge, like that pal who tells you you’ve got spinach in your teeth but with way more code.
1. Forgetting Semantic HTML: The Backbone of Accessibility
Here’s a classic. Ever seen a site that’s basically a soup of <div> tags? Yeah, guilty as charged, especially in my early days. Semantic HTML isn’t just about making your markup pretty; it’s the foundation screen readers lean on to understand your page’s structure.
Imagine you’re navigating a site with a screen reader. Without proper tags like <header>, <nav>, <main>, or <footer>, the experience becomes a labyrinth. Users can’t jump to the main content or skip repetitive menus. It’s like walking into a building with no signs.
How to fix this: Use semantic elements wherever possible. Instead of generic <div>s, wrap your navigation in <nav>, your main content in <main>, and so on. It’s easy, and it pays off big time.
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
</ul>
</nav>
<main>
<article>
<h1>Welcome to my site</h1>
<p>Here's some important content.</p>
</article>
</main>2. Missing or Poor Alt Text: The Silent Accessibility Killer
Alt text. If I had a dollar for every time I saw images without alt attributes or with “image” as alt text, I could retire early. The thing is, alt text isn’t just a formality — it’s the lifeline for users who rely on screen readers. Without it, images become invisible or confusing.
But here’s a nuance: not all images need descriptive alt text. Decorative images should have an empty alt attribute like alt="" to tell screen readers to skip them. Otherwise, you’re just adding noise.
I remember a project where a huge hero image had alt=”hero image”. Utterly useless. I replaced it with a concise, meaningful description and suddenly users could understand the visual context. It’s all about purpose.
Pro tip: Write alt text like you’re describing the image to someone over the phone. Be clear, concise, and avoid redundancy.
<img src="portrait.jpg" alt="Photo of Jane smiling at a sunny park" />
<img src="decorative-stars.png" alt="" /> <!-- This image is purely decorative -->3. Insufficient Keyboard Navigation Support
Ever tried tabbing through a website only to get stuck or lost? That’s a red flag. Keyboard users—including many people with mobility impairments—need to navigate seamlessly without a mouse.
A mistake I used to make: relying on JavaScript-driven components that aren’t keyboard-friendly out of the box. Dropdowns that only open on click, modals that trap focus incorrectly, buttons not reachable via keyboard—all frustrating.
How to check? Just hit Tab and see where you land. If the focus disappears or skips things, that’s your cue to fix.
Fixing the basics:
- Use native HTML controls (like
<button>) which come with built-in keyboard support. - When building custom widgets, manage
tabindexand focus states carefully. - Ensure focus moves logically and visibly.
- Test with keyboard only—no cheating!
4. Poor Color Contrast and Reliance on Color Alone
Color can be beautiful, but it’s a trap when it’s the only way you communicate something. Ever seen a form where errors are only indicated by a red border? Not great.
Low contrast text or UI elements make life harder for people with visual impairments or color blindness. And yes, it’s easy to miss until you step back and test.
I once designed a neat blue-on-purple button that looked sleek but failed contrast checks miserably. When I swapped it out for a more contrasting combo, it wasn’t just compliant—it was easier on everyone’s eyes.
Tools to help: Use the WebAIM Contrast Checker or browser extensions like Axe or Lighthouse to catch issues early.
5. Overusing ARIA or Misapplying It
ARIA is like the spice of accessibility—it’s powerful but easy to misuse. Early in my career, I thought slapping ARIA roles everywhere was the shortcut to accessibility. Nope. Overusing ARIA can confuse assistive tech or even break native semantics.
Rule of thumb? Use semantic HTML first, then sprinkle ARIA only to fill gaps. For example, don’t add role="button" to a native <button>. It’s redundant and potentially harmful.
Always check ARIA roles with tools like Paciello Group’s ARIA Role Model or WAI-ARIA Authoring Practices. They’re gold mines.
6. Ignoring Focus Indicators
Focus indicators—the little outlines or highlights around elements when you tab through—are a simple but critical accessibility feature. They tell keyboard users exactly where they are on the page.
It’s tempting to remove those ugly outlines for a sleeker look. I confess, I’ve done it. But it’s a rookie mistake.
If you must customize focus styles, make sure they’re visible and obvious. Don’t make users hunt for the cursor like they’re on a scavenger hunt.
Here’s a simple CSS snippet to keep focus visible but stylish:
button:focus, a:focus {
outline: 3px solid #005fcc;
outline-offset: 2px;
}7. Not Testing with Real Assistive Technologies
This one’s on me, and maybe you too: relying solely on automated tools for accessibility checks. They’re handy but can’t replace the human element.
Try this: grab a screen reader like NVDA (Windows) or VoiceOver (Mac), and actually navigate your site. It’s eye-opening. You’ll hear what works, what’s confusing, and what’s missing.
Also, test keyboard-only navigation, and if you can, try switching to high contrast modes or zooming in. Real-world conditions often expose sneaky issues automated tools miss.
Wrapping It Up: Accessibility is a Journey, Not a Checklist
So there you have it—some of the most common HTML accessibility mistakes and how to fix them. If you’re nodding along, thinking, “Yeah, I’ve done that,” you’re in good company. Accessibility isn’t a switch you flip overnight—it’s a mindset, a craft you hone with patient, deliberate practice.
Next time you’re building something, start with semantic HTML, think about keyboard users, write meaningful alt text, and don’t be afraid to test with actual assistive technology. It’s like tuning a musical instrument: small adjustments make all the difference.
Honestly? Sometimes it feels like swimming upstream, but the payoff is huge. You’re opening doors for folks who might otherwise be locked out—and that’s worth every moment.
So… what’s your next move? Try running an accessibility audit on your latest project. Or maybe just pick one of these mistakes you’ve caught yourself making and fix it. Give it a shot, and see what clicks.
