I’ll be honest—when I first started building web applications, accessibility wasn’t something I paid much attention to. It wasn’t that I didn’t care; I just didn’t realize how many people struggle to use websites due to poor design choices. But after facing real-world issues and receiving feedback from users who had trouble navigating my apps, I knew I had to do better.

So, if you’ve ever overlooked accessibility (like I did), don’t worry—you’re not alone. Let’s talk about some common accessibility pitfalls in frontend development and how we can avoid them.

1. Ignoring Semantic HTML

One of the first mistakes I made was relying too much on <div> and <span> elements for everything. The problem? Screen readers and assistive technologies struggle to interpret them properly.

How to Fix It:

• Use semantic HTML elements (<header>, <nav>, <main>, <button>, <form>, etc.).
• Reserve <div> and <span> for styling purposes only.
• Ensure that interactive elements (like buttons and links) are actually clickable and labeled correctly.

2. Poor Keyboard Navigation

Ever tried navigating your website using only the keyboard? If not, you might be surprised how frustrating it can be when key elements aren’t accessible via Tab or Enter.

How to Fix It:

• Ensure all interactive elements are focusable.
• Use tabindex="0" for elements that should be reachable and tabindex="-1" for those that shouldn’t.
• Test navigation by pressing Tab and Enter through your site.

3. Insufficient Color Contrast

I once built a sleek dark-themed UI, only to realize later that many users found it hard to read. Low contrast between text and background can make content unreadable for visually impaired users.

How to Fix It:

• Use tools like WebAIM Contrast Checker or Google Lighthouse to test contrast ratios.
• Ensure text has a contrast ratio of at least 4.5:1 (for normal text) and 3:1 for large text.
• Avoid using color alone to convey important information (e.g., don’t just use red for errors—add an icon or text too).

4. Missing or Poorly Written Alt Text

Images without alt attributes create problems for users who rely on screen readers. I’ve made the mistake of either skipping alt text entirely or using vague descriptions like "image1.jpg"—not helpful!

How to Fix It:

• Always provide meaningful alt text that describes the content and function of the image.
• If an image is decorative, use alt="" to indicate it should be ignored by screen readers.
• Avoid redundancy—if a caption already describes the image, you can leave alt="".

5. Forgetting ARIA Landmarks and Roles

ARIA (Accessible Rich Internet Applications) attributes help enhance accessibility, but misusing them can make things worse.

How to Fix It:

• Use landmark roles like role="banner", role="navigation", and role="main" to help assistive technologies navigate your site.
• Use aria-live for dynamic content updates so screen readers announce changes properly.
• Avoid adding unnecessary ARIA roles to native elements (e.g., don’t add role="button" to an actual <button>).

6. Overlooking Form Accessibility

Forms were a nightmare for me until I learned how important proper labeling is. Users with disabilities often struggle to understand form inputs without clear labels.

How to Fix It:

• Use <label> elements and associate them with inputs using for or aria-labelledby.
• Use aria-describedby to provide additional instructions.
• Ensure error messages are accessible, not just visually but also programmatically.

7. Not Providing Alternative Input Methods

Relying only on mouse interactions can alienate users who navigate using keyboards, touch screens, or voice commands.

How to Fix It:

• Ensure buttons and links are keyboard-accessible.
• Support gestures like swiping for mobile users.
• Enable voice commands using tools like Web Speech API where applicable.

8. Skipping Accessibility Testing

I used to think that accessibility testing was optional—until I realized it’s the only way to truly know if a site is usable for everyone.

How to Fix It:

• Use screen readers like NVDA (Windows) or VoiceOver (Mac) to navigate your site.
• Run automated tests with Google Lighthouse or axe DevTools.
• Get real feedback from users with disabilities if possible.

Final Thoughts

Accessibility isn’t just about compliance—it’s about creating an inclusive experience for everyone. Once I started making accessibility a priority, I saw a huge difference in user engagement and satisfaction.

If you’re building websites, don’t wait until the last minute to think about accessibility. Start now, test often, and make the web a better place for everyone.