hey jonny! đź‘‹

Web Accessibility: Not Just Nice to Have, But Essential

Last month, I watched my grandmother try to use a banking website. She’s 78, has mild vision issues, and isn’t the most tech-savvy person. What should have been a simple task—checking her account balance—turned into a 20-minute frustration fest. The text was too small, the buttons weren’t clearly labeled, and the contrast was so poor she couldn’t distinguish between different sections.

That’s when it hit me: accessibility isn’t about compliance checkboxes or legal requirements. It’s about building web experiences that work for actual human beings.

The Reality Check

Here are some statistics that might surprise you:

But accessibility isn’t just about permanent disabilities. It’s also about:

We’re all temporarily able-bodied.

Common Accessibility Sins (And How to Fix Them)

1. The Color-Only Information Problem

❌ Wrong:

<span style="color: red;">Required field</span>

âś… Better:

<span style="color: red;">
  <span aria-label="Required">*</span>
  Required field
</span>

Don’t rely solely on color to convey information. Add icons, text, or other visual indicators.

2. The Mystery Meat Navigation

❌ Wrong:

<button>
  <svg>...</svg>
</button>

âś… Better:

<button aria-label="Close dialog">
  <svg aria-hidden="true">...</svg>
</button>

Icon-only buttons are confusing for screen reader users. Always provide descriptive labels.

3. The Keyboard Trap

❌ Wrong:

button:focus {
  outline: none;
}

âś… Better:

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

Never remove focus indicators without providing an alternative. Many users navigate exclusively with keyboards.

4. The Phantom Form Error

❌ Wrong:

<input type="email" required>
<div id="error" style="color: red; display: none;">
  Invalid email
</div>

âś… Better:

<input type="email" required aria-describedby="email-error">
<div id="email-error" role="alert" style="color: red; display: none;">
  Invalid email address. Please use format: name@example.com
</div>

Connect form errors to their inputs and provide clear, actionable error messages.

The ARIA Toolkit (Use Wisely)

ARIA (Accessible Rich Internet Applications) is powerful, but it’s often misused. Here are the golden rules:

Rule #1: Semantic HTML First

<!-- Don't do this -->
<div role="button" tabindex="0" onclick="doSomething()">
  Click me
</div>

<!-- Do this instead -->
<button onclick="doSomething()">
  Click me
</button>

If there’s a semantic HTML element for what you’re building, use it.

Rule #2: ARIA Labels for Context

<button aria-label="Delete user John Smith">
  🗑️
</button>

<input aria-label="Search products" placeholder="Enter product name...">

Provide context that isn’t visually obvious.

Rule #3: Live Regions for Dynamic Content

<div aria-live="polite" id="status">
  <!-- Status updates appear here -->
</div>

<div aria-live="assertive" id="errors">
  <!-- Critical errors appear here -->
</div>

Announce dynamic content changes to screen reader users.

Building Accessible Components

The Accessible Modal

<div role="dialog" aria-labelledby="modal-title" aria-modal="true">
  <div class="modal-header">
    <h2 id="modal-title">Confirm Deletion</h2>
    <button aria-label="Close modal" onclick="closeModal()">Ă—</button>
  </div>
  <div class="modal-body">
    <p>Are you sure you want to delete this item?</p>
  </div>
  <div class="modal-footer">
    <button onclick="confirmDelete()">Delete</button>
    <button onclick="closeModal()">Cancel</button>
  </div>
</div>

Key features:

The Accessible Dropdown

<div class="dropdown">
  <button 
    aria-expanded="false" 
    aria-haspopup="true"
    aria-controls="dropdown-menu"
    id="dropdown-trigger">
    Options â–Ľ
  </button>
  <ul id="dropdown-menu" role="menu" hidden>
    <li role="none">
      <button role="menuitem">Edit</button>
    </li>
    <li role="none">
      <button role="menuitem">Delete</button>
    </li>
  </ul>
</div>

Features arrow key navigation, proper ARIA states, and escape key handling.

Testing Your Accessibility

Automated Testing Tools

axe DevTools: The gold standard browser extension

// You can also integrate axe into your test suite
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

test('should not have accessibility violations', async () => {
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Lighthouse: Built into Chrome DevTools with accessibility audits

Manual Testing Checklist

  1. Keyboard Navigation: Can you use the entire interface with just Tab, Enter, Space, and arrow keys?

  2. Screen Reader Testing: Use NVDA (Windows), JAWS (Windows), or VoiceOver (Mac) to navigate your site

  3. Color Contrast: Use tools like WebAIM’s contrast checker to ensure sufficient contrast ratios

  4. Zoom Testing: Zoom to 200% and ensure everything still works

  5. Focus Management: Make sure focus moves logically and is always visible

The Business Case for Accessibility

Beyond doing the right thing, accessibility makes business sense:

Larger Market Reach

SEO Benefits

Better UX for Everyone

Accessibility-First Design Principles

1. Perceivable

2. Operable

3. Understandable

4. Robust

Common Misconceptions

”Accessibility is Ugly”

False. Look at GitHub, BBC, or gov.uk. Beautiful design and accessibility go hand in hand.

”Accessibility is Expensive”

Partially true. Retrofitting is expensive. Building accessibly from the start is cheap.

”Blind Users Don’t Use Images”

False. Screen readers read alt text. Many users with low vision use screen magnifiers.

”ARIA Fixes Everything”

Dangerous thinking. ARIA should supplement, not replace, semantic HTML.

Getting Started Today

1. Audit Your Current Site

Run Lighthouse and axe on your key pages. Fix the obvious issues first.

2. Establish Guidelines

Create accessibility guidelines for your team. Include them in your definition of done.

3. Learn Gradual Enhancement

Build from a solid HTML foundation, then enhance with CSS and JavaScript.

4. Test with Real Users

Nothing beats testing with actual users who rely on assistive technology.

The Path Forward

Accessibility isn’t a destination—it’s an ongoing practice. Start small:

  1. Fix color contrast issues
  2. Add proper alt text to images
  3. Ensure keyboard navigation works
  4. Add focus indicators
  5. Use semantic HTML elements

Every small improvement makes the web more inclusive for everyone.

Remember my grandmother and her banking struggle? After I showed the bank’s UX team her experience, they redesigned their interface. Six months later, she called me excited—she had successfully paid her bills online for the first time.

That’s the power of accessible design. It doesn’t just check compliance boxes. It gives people independence, dignity, and equal access to information.

The web should work for everyone. Let’s make sure it does.

Want to learn more? Check out WebAIM and the a11y Project for excellent accessibility resources.