Back to News/97% of Websites Fail Accessibility Tests — Here's What You're Doing Wrong

97% of Websites Fail Accessibility Tests — Here's What You're Doing Wrong

Most developers think accessibility is 'not urgent' until they get sued. Learn WCAG 2.2, POUR principles, and implementation techniques you can apply immediately before your digital presence becomes a legal nightmare — and more importantly — a human failure.

Faisal Affan
4/1/2026
97% of Websites Fail Accessibility Tests — Here's What You're Doing Wrong — 1 / 2
1 / 2

Accessibility: When Digital Must Leave No One Behind

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." — Tim Berners-Lee, W3C Director


Why Should You Read This Article?

3 Quick Reasons

1. Legal risk — 4,000+ accessibility lawsuits in the US in 2024 2. 15% of population — has limitations, and most developers skip this 3. SEO benefit — accessibility = better HTML structure

Critical Statistics

1.3 billion people with disabilities globally. 97% of homepages don't meet basic standards. Assistive technology market: $30 billion+.


Overview: What Is Accessibility (A11y)?

Accessibility (A11y) = the practice of making digital products usable by everyone, including people with disabilities.

Two Standards You Must Know

Prop

Type

WCAG Principles: POUR


Spectrum of Disabilities to Accommodate

Prop

Type


WCAG Levels: Which Should You Target?

Level A — Minimum

Basic requirements. If you miss these, your website will fail accessibility tests.

Level AA — Industry Standard

Target for most regulations. Reasonable compliance for大多数 organizations.

Level AAA — Strict

Full compliance rarely required. Strictest requirements.

Recommendation

Target WCAG AA as your baseline compliance. This is what most international regulations use.


Risks If You Skip Accessibility

4 Main Risks:

RiskImpact
LegalLawsuits in US/EU markets — can be very expensive
Users15-20% of population with limitations can't use your product
SEOPoor HTML structure = SEO suffers
BrandNon-inclusive = damaged brand image

WCAG 2.2: 9 New Things You Need to Know

The latest version (October 2023) added 9 new Success Criteria:

Elements with focus must not be hidden by sticky headers.

Focus indicator must have 3:1+ contrast and sufficient area.

All drag-and-drop must have single-pointer alternatives (up/down buttons).

Interactive targets minimum 24x24 CSS pixels.

Adequate clearance for smaller targets.

Help mechanism on one page = help on all pages with consistent position.

Don't request information already input previously.

Cognitive puzzle CAPTCHAs not allowed — provide alternatives.

No part of focused element may be hidden.


Americans with Disabilities Act (ADA)

Prop

Type

Since Facebook v. Nizzud (2019) and Domino's Pizza v. Laredo (2019), courts have consistently ruled that ADA applies to websites.

Section 508

For US federal entities, all EICT must meet Access Board standards.


Practical Implementation: From Theory to Code

1. Semantic HTML: The Foundation You Can't Skip

Use HTML elements according to their function:

<!-- ❌ Bad: Not semantic -->
<div class="header">
  <div class="nav">
    <div class="logo">Brand</div>
  </div>
</div>

<!-- ✅ Good: Semantic with landmarks -->
<header>
  <nav aria-label="Main navigation">
    <a href="/" aria-label="Home">Brand</a>
  </nav>
</header>
<main id="main-content">
  <article>...</article>
</main>
<footer>...</footer>

Opinion

Use <button> instead of <div> for interactive elements. Screen readers need to know this is a button.

2. Alt Text: Description for Those Who Can't See

Prop

Type

3. Keyboard Navigation: Focus and Tab Order

Ensure tab order follows visual reading order. Avoid positive tabindex.

Never remove outline without a clear alternative.

Ensure no element traps keyboard users.

Provide mechanism to disable/remap single-key shortcuts.

/* ✅ Good: Clear focus indicator */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

/* ❌ Bad: outline: none without alternative */
button:focus {
  outline: none;
}
<!-- Place as first element in body -->
<a href="#main-content" class="skip-link">
  Skip to main content
</a>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #005fcc;
  color: white;
  padding: 8px 16px;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

5. Color Contrast: Not Just Aesthetics

WCAG Contrast Requirements

  • 4.5:1 — Normal text (AA)
  • 3:1 — Large text 18pt+ or 14pt+ bold (AA)
  • 3:1 — Component states and graphical objects (AA)
:root {
  /* ✅ Good: Sufficient contrast */
  --text-primary: #1a1a2e;   /* 15.5:1 against white */
  --text-secondary: #4a4a68; /* 7.2:1 against white */

  /* ❌ Bad: Insufficient contrast */
  --text-muted: #888888; /* 2.8:1 against white */
}

6. ARIA: Use Wisely

Primary ARIA Rule

If native HTML is sufficient, use HTML. ARIA doesn't make elements more accessible — it just adds information for assistive technology.

// ❌ Bad: Unnecessary ARIA
<div role="button" tabindex="0" onClick={handleClick}>
  Submit
</div>

// ✅ Good: Native HTML
<button type="submit">Submit</button>

// ❌ Bad: Label not connected
<input type="text" placeholder="Email" />

// ✅ Good: Explicit association
<label htmlFor="email">Email</label>
<input id="email" type="email" />

7. Forms: Informative Error Handling

<label htmlFor="password">Password</label>
<input
  id="password"
  type="password"
  aria-describedby="password-requirements password-error"
  aria-invalid="true"
/>
<p id="password-requirements">
  Minimum 8 characters, 1 uppercase, 1 number
</p>
<p id="password-error" role="alert">
  Password must contain at least 8 characters
</p>

Tools: Audit, Testing, Monitoring

Automated Testing (Fast, Scalable)

Google Lighthouse

Built-in Chrome DevTools. Quick audit with score + suggestions.

npx lighthouse https://example.com --only-categories=accessibility

axe DevTools

More accurate than Lighthouse. Has CI/CD version.

npm install @axe-core/react

Pa11y

CLI tool — suitable for pipeline automation.

npx pa11y https://example.com

Accessibility Insights

Step-by-step audit + guided fixes from Microsoft.

Screen Reader Testing: Ground Truth

Opinion: 80% of devs skip screen reader testing. This is the biggest blind spot.

Testing with real assistive technology is the only way to know the actual user experience.

Prop

Type

Contrast & Visual Tools

Prop

Type

Manual Testing Checklist

  • Tab navigation without mouse — all functions accessible?
  • Focus state clear — visible?
  • Forms work with keyboard — all inputs reachable?
  • No "traps" — modals/dropdowns can be escaped?

Testing Checklist: Before Launch

Pre-Launch Checklist

  • Keyboard-only navigation: all functions accessible without mouse?
  • Screen reader: reading order logical?
  • Zoom 200%: content still usable?
  • High contrast mode: all elements visible?
  • Reduced motion: animations respect prefers-reduced-motion?

Healthcare Apps: Additional Checklist

Prop

Type

HIPAA + ADA

In healthcare, compliance isn't just WCAG — must align with HIPAA Privacy Rule. Some accessibility accommodations must consider HIPAA implications.


Action Plan: Where to Start?

Priority 1: Security Mindset

Treat accessibility like a vulnerability. Broken accessibility = UX vulnerability. Like security, it must be integrated from the start.

Priority 2: WCAG AA Minimum Checklist

  • Alt text for all images
  • Keyboard fully usable
  • Contrast ≥ 4.5:1
  • Clear form labels
  • ARIA only when needed

Priority 3: Minimum Stack

  1. Lighthouse — quick check
  2. axe DevTools — debug
  3. NVDA / VoiceOver — manual reality check

Priority 4: Production-Grade

  • Pa11y / axe CI integration
  • Design system enforce contrast + semantics
  • Fail build if accessibility score < threshold

First-Principles: Accessibility ≈ API Contract for Humans

Insight

If APIs must be predictable for machines, then UI must be predictable for humans with various limitations.

Engineers who understand this typically:

  • Write more semantic code
  • Build more robust UX
  • Have fewer bugs

Accessibility Tools = Observability Layer for UX

Without these:

  • UI looks "normal"
  • But broken for some users

With these:

  • UX becomes measurable (like latency / error rate)

Conclusion

Accessibility is not a feature added at the end — it is a fundamental architecture principle.

Final Action Items

  1. Audit current state with axe-core or Lighthouse
  2. Fix high-impact issues: keyboard navigation, alt text, color contrast
  3. Implement skip links and focus management
  4. Add accessibility to Definition of Done
  5. Regular testing with assistive technology

Good accessibility = good design. When we build for edge cases, the entire user experience improves.

A truly universal digital product works for everyone, without exception.


References

Prop

Type


Related Articles

97% of Websites Fail Accessibility Tests — Here's What Yo... | Faisal Affan