Skip to main content

Accessibility Testing

Ensure systems work for users with disabilities and comply with accessibility standards.

TL;DR

Accessibility testing ensures systems work for users with disabilities (visual, hearing, motor, cognitive). WCAG 2.1 is the standard: Level A (basic), Level AA (recommended), Level AAA (advanced). Most organizations target AA. Test for: color contrast (4.5:1 for normal text), alt text on images, keyboard navigation, screen reader compatibility, captions on videos, form labels. Use automated tools (axe, Lighthouse) to catch common issues; manual testing with actual assistive technologies (screen readers, magnifiers) to find edge cases. Accessibility is not an afterthought—design and test from the start.

Learning Objectives

After reading this article, you will understand:

  • WCAG 2.1 standards and accessibility levels (A, AA, AAA)
  • Common accessibility issues and how to fix them
  • Automated vs. manual accessibility testing
  • How to test with assistive technologies (screen readers, voice control)
  • Accessible design patterns and best practices
  • How to integrate accessibility testing into development workflow

Motivating Scenario

Your e-commerce site works great for most users. But when a blind user tries to purchase with a screen reader, they can't complete checkout because form fields aren't labeled. A hearing-impaired user can't watch your product demos because videos lack captions. A motor-impaired user can't navigate using just the keyboard because focus indicators are invisible.

Accessibility testing catches this: Automated tests find missing alt text and poor color contrast. Manual testing with actual assistive technologies uncovers keyboard navigation and screen reader issues. By testing with accessibility in mind, you serve all users.

Core Concepts

WCAG 2.1 Standards

WCAG 2.1 defines three conformance levels; most target Level AA

Four Principles (POUR):

  1. Perceivable: Users can see/hear content (color contrast, alt text, captions)
  2. Operable: Users can navigate (keyboard, focus indicators, no traps)
  3. Understandable: Content is clear (plain language, consistent labels)
  4. Robust: Works with assistive technologies (semantic HTML, ARIA labels)

Common Accessibility Issues and Fixes

IssueProblemFix
Poor color contrastUnreadable for low-vision usersEnsure 4.5:1 contrast ratio
Missing alt textImages invisible to screen readersAdd descriptive alt text
No keyboard navigationCan't use without mouseUse Tab key, focus indicators
Unlabeled form fieldsScreen readers can't explain fields<label> tags or ARIA labels
No video captionsDeaf users can't watchAdd captions/transcripts
Unclear focus indicatorCan't see where keyboard isAdd visible focus styling
Color-only informationColorblind users miss meaningUse icons, patterns, labels too

Practical Example

<!-- Inaccessible form -->
<form>
Email: <input type="email" name="email">
Password: <input type="password" name="password">
<input type="checkbox"> Remember me
<button>Login</button>
</form>

<!-- Accessible form -->
<form>
<div class="form-group">
<label for="email">Email address</label>
<input type="email" id="email" name="email" required aria-describedby="email-help">
<small id="email-help">We'll never share your email</small>
</div>

<div class="form-group">
<label for="password">Password</label>
<input type="password" id="password" name="password" required>
</div>

<div class="form-group">
<input type="checkbox" id="remember" name="remember">
<label for="remember">Remember me for 30 days</label>
</div>

<button type="submit">Login</button>
</form>

<!-- Accessible image -->
<img src="product.jpg" alt="Blue wireless headphones with noise cancellation">

<!-- Inaccessible heading -->
<div style="font-size: 24px; font-weight: bold;">Products</div>

<!-- Accessible heading -->
<h1>Products</h1>

<!-- Accessible link (not "Click here") -->
<a href="/about">Learn more about our company</a>

<!-- Accessible video -->
<video controls>
<source src="demo.mp4" type="video/mp4">
<track kind="captions" src="demo-captions.vtt" srclang="en" label="English">
Your browser doesn't support HTML5 video.
</video>

<!-- Accessible color with pattern -->
<div style="background: #ff0000; color: white;">
Status: <span style="color: #ff0000;"></span> Failed
</div>

When to Use / When Not to Use

Use Accessibility Testing When:
  1. You have any public-facing application or website
  2. You serve diverse users (government, healthcare, finance do)
  3. Legal compliance is required (ADA, WCAG mandates)
  4. You want to expand your audience to all users
  5. You're building features with rich interactions
Avoid (but reconsider):
  1. Internal tools only (still should be accessible)
  2. No disabled users (yet—expand your audience)
  3. Too expensive to fix (it's usually cheaper than lawsuits)

Patterns and Pitfalls

Accessibility Testing Best Practices and Anti-Patterns

Design for accessibility first: Build accessible from the start; retrofitting is hard. Test with real assistive tech: Automated tools catch 30-40%; screen readers find the rest. Follow semantic HTML: Use proper tags (h1, label, button) not styled divs. Provide alt text: Describe images for screen reader users; include context. Keyboard navigation everywhere: Tab, Enter, Escape should work. Test with actual users: People with disabilities find issues you'll miss. Define SLOs: 'No critical violations' doesn't cut it; aim for AA. Automate and manual: Combine axe, Lighthouse with manual testing.
Ignoring accessibility: Building without considering it. Only automated testing: Axe catches obvious issues; manual testing finds subtle ones. Placeholder labels: <input placeholder='Email'> is not a label. Color-only: Status shown only by color; add icons/text. Skip keyboard: 'Most users have mice' ignores disabled users. Poor focus indicators: Removing focus styling to look fancy; breaks keyboard nav. No captions: Videos without captions lock out deaf users. Accessibility theater: Running axe, seeing zero violations, claiming victory (doesn't mean it's accessible).

Design Review Checklist

  • WCAG 2.1 Level AA is the target (minimum: Level A)
  • Color contrast is at least 4.5:1 for normal text
  • All images have meaningful alt text
  • Videos have captions and transcripts
  • All form inputs have associated labels
  • Keyboard navigation works for all interactive elements
  • Focus indicators are visible and clear
  • Page structure is semantic (h1, h2, lists, etc.)
  • Link text is descriptive (not 'Click here')
  • Error messages are clear and helpful
  • No information conveyed by color alone
  • Interactive elements are at least 44x44 pixels (touch targets)
  • Automated testing (axe, Lighthouse) runs in CI/CD
  • Manual testing with screen readers completed
  • ARIA attributes used correctly (not div role=button)

Self-Check Questions

  • Q: What's the difference between WCAG A, AA, and AAA? A: A = basic (bare minimum), AA = enhanced (recommended), AAA = advanced (hard to achieve). Most target AA.

  • Q: Why is alt text important? A: Screen reader users can't see images. Alt text describes the image. Decorative images can have empty alt="".

  • Q: Can you just use color to show errors? A: No. Color-blind users won't see it. Add an icon, text, or other indicator too.

  • Q: Is keyboard navigation just for screen reader users? A: No. People with mobility disabilities use keyboard. Motor-impaired users use switch controls. Test keyboard thoroughly.

  • Q: Do we really need captions on videos? A: Yes. Deaf users need them. Even hearing users in loud places appreciate captions.

Next Steps

  1. Audit current accessibility — Run Lighthouse, axe to find issues
  2. Prioritize fixes — Critical (blocking access) → Important → Nice-to-have
  3. Define SLOs — "No Level A violations; minimal Level AA"
  4. Make design accessible — Semantic HTML, color contrast, spacing
  5. Test with assistive tech — Screen readers, magnifiers, switch control
  6. Train the team — Accessibility isn't QA's job; everyone owns it
  7. Automate testing — axe, Lighthouse in CI/CD
  8. Involve users — Test with actual people who use assistive tech

References

  1. WCAG 2.1 Quick Reference ↗️
  2. Axe DevTools Accessibility Scanner ↗️
  3. NVDA Screen Reader (Free) ↗️
  4. WebAIM Color Contrast Checker ↗️
  5. W3C Testing and Evaluation ↗️