Muhammed's Blog

Web Accessibility - Making Your App Usable for Everyone

It’s Not Just About Screen Readers (But Yes, Also Screen Readers)

2 min read

15% of the world has a disability. That’s 1 billion people. If your app isn’t accessible, you’re excluding a massive audience. Plus, accessible apps are better for everyone.

Why Accessibility Matters

I built a beautiful image gallery. Hover effects, smooth animations, perfect aesthetics. Then I got an email: “I’m blind and use a screen reader. Your gallery just reads ‘image, image, image’ with no context.”

That day, I learned: Accessibility isn’t an afterthought. It’s fundamental to good development.

Accessibility helps:

  • Disabled users (visual, motor, hearing, cognitive)
  • Everyone (keyboard power users, sunlight readability, captions in noisy environments)

Quick Wins (Fix These Today)

1. Alt Text - Describe images for screen readers:

<!-- Bad: No alt -->
<img src="profile.jpg">

<!-- Good: Descriptive -->
<img src="profile.jpg" alt="John Doe smiling in front of mountains">

2. Semantic HTML - Use actual elements, not divs:

<button onclick="submit()">Submit</button>  <!-- not <div class="button"> -->
<nav>Navigation</nav>  <!-- not <div class="nav"> -->
<main>Content</main>

3. Keyboard Navigation - Tab, Enter, Escape must work everywhere.

4. Focus Indicators - Never remove them without replacing:

button:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

5. Color Contrast - WCAG requires 4.5:1 ratio for normal text. Use WebAIM Contrast Checker.

6. Form Labels - Proper <label> tags, not just visual:

<label for="email">Email</label>
<input type="email" id="email">

7. Descriptive Links - “Read documentation” not “Click here”.

ARIA Essentials

ARIA adds semantic meaning when HTML isn’t enough:

  • aria-label="Close" - Label icon buttons
  • aria-labelledby="id" - Link element to heading
  • aria-describedby="id" - Describe form errors
  • aria-hidden="true" - Hide decorative elements from screen readers
  • aria-live="polite" - Announce dynamic content updates
  • role="dialog", role="tab", role="alert" - Define component types

Testing for Accessibility

Automated: axe DevTools, WAVE, Lighthouse catch 80% of issues.

Manual:

  • Tab through entire site (keyboard only)
  • Test at 200% zoom
  • Try VoiceOver (Mac Cmd+F5) or NVDA (Windows)

Real users: Services like Fable connect you with disabled testers. Best test available.

Common Mistakes

  • Icon-only buttons without aria-label
  • Opening new windows without warning
  • Relying only on color (add icons, text, patterns too)
  • Auto-playing media (let users control)
  • Images without dimensions (causes layout shift)

The Accessibility Checklist

  • All images have alt text
  • Semantic HTML throughout
  • All interactive elements keyboard accessible
  • Focus indicators visible
  • Color contrast ≥4.5:1
  • Forms have proper labels
  • Links descriptive (not “click here”)
  • Headings logical order (h1, h2, h3)
  • Page language set (<html lang="en">)
  • No auto-playing media

Resources

Accessibility isn’t optional. It’s not a nice-to-have.

1 billion people have disabilities. Accessible apps benefit everyone.

Start small. Fix alt text today. Add keyboard navigation tomorrow. Use semantic HTML.

Build for everyone. The web is for everyone.