A11y Testing: The Missing Piece in Your QA Workflow

Let me ask you something: when was the last time you thought about accessibility testing in your project? If your answer is "never" or "I meant to get around to that," you're definitely not alone. Most of us are pretty good at writing unit tests, maybe some integration tests — but a11y (accessibility) tests? That's the one that tends to fall through the cracks.

Today I want to share what I learned about a11y testing — what it is, why it matters more than you probably think, and how you can actually start doing it without turning your whole workflow upside down.

---

What Even Is A11y Testing?

First things first — "a11y" is a numeronym for accessibility. The "11" represents the 11 letters between the "a" and the "y". Nerdy? Yes. Useful shorthand? Absolutely.

Accessibility testing is the practice of checking whether your web application (or any software, really) can be used by people with disabilities. That includes people who:

• Use screen readers (like NVDA or VoiceOver)
• Navigate with a keyboard instead of a mouse
• Have low vision and rely on high contrast or zoomed interfaces
• Have cognitive or motor disabilities

The goal is to make sure your app follows standards — primarily the WCAG (Web Content Accessibility Guidelines) — so that everyone can use what you've built.

---

Why Should Developers Care?

Here's the honest answer: because it's the right thing to do and it's increasingly the smart business move.

• ~1 in 4 adults in the US has some form of disability (CDC data)
• Inaccessible apps can create legal liability — lawsuits around web accessibility have been rising steadily
• Good accessibility practices often improve SEO and overall UX for everyone
• It's way cheaper to build it right from the start than to retrofit it later

And beyond the numbers: imagine building something you're proud of that a chunk of your users simply can't use. That's a problem worth solving.

---

Types of A11y Tests

Not all accessibility testing looks the same. There are basically three flavors:

1. Automated Testing

Tools that scan your code or rendered DOM and flag common accessibility violations automatically. Think of it as a linter, but for accessibility.

Popular tools:

• axe-core — the most widely used accessibility engine
• jest-axe — integrates axe into Jest tests
• @testing-library/jest-dom — helpful matchers for accessible queries
• Lighthouse (built into Chrome DevTools)

Here's a quick example of using jest-axe:

import React from 'react';
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

it('should have no accessibility violations', async () => {
  const { container } = render(<MyButton label="Click me" />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

That's it. Seriously. You add that test, run your suite, and you'll get a detailed report if anything fails accessibility checks.

2. Manual Testing

Automated tools are great, but they only catch around 30-40% of accessibility issues. The rest require a human.

Manual testing means things like:

• Tabbing through your UI with just a keyboard
• Running a screen reader (NVDA on Windows, VoiceOver on Mac) and actually listening to your page
• Checking color contrast ratios manually
• Testing with browser zoom set to 200%

It's a bit more effort, but it's genuinely eye-opening. You'll probably discover UI quirks you never noticed before.

3. User Testing

The gold standard. Actually getting feedback from users who have disabilities and rely on assistive technology day-to-day. This isn't always feasible for every team, but if you can do it — do it.

---

Getting Started: Low-Hanging Fruit

You don't have to overhaul everything overnight. Here are some quick wins you can implement today:

Use semantic HTML. This one is free and incredibly impactful.

<!-- Bad -->
<div onclick="handleClick()">Submit</div>

<!-- Good -->
<button type="submit">Submit</button>

Screen readers know what a <button> is. A <div> with a click handler? Not so much.

Add alt text to images.

<!-- Bad -->
<img src="profile.jpg" />

<!-- Good -->
<img src="profile.jpg" alt="Profile photo of Jane Doe" />

Make sure form inputs have labels.

<!-- Bad -->
<input type="email" placeholder="Enter email" />

<!-- Good -->
<label for="email">Email address</label>
<input id="email" type="email" />

Don't rely on color alone to communicate information. Add icons, text, or patterns as a backup.

---

Integrating A11y Tests Into Your CI Pipeline

Once you've written a few a11y tests, you'll want to make sure they run automatically so regressions don't sneak in. Most CI setups (GitHub Actions, GitLab CI, CircleCI) will just pick them up as part of your regular test run if you're using Jest.

You can also add Lighthouse CI for automated audits on every pull request:

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [push]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
          budgetPath: ./budget.json

This way, accessibility scores become part of your pull request feedback loop — just like test coverage.

---

Common A11y Mistakes Developers Make

Before I wrap up, here's a quick hit list of the most common slip-ups:

• ❌ Missing or generic alt text (e.g., alt="image")
• ❌ Low color contrast between text and background
• ❌ Interactive elements that aren't keyboard-focusable
• ❌ No aria-label on icon-only buttons
• ❌ Modals that trap focus or don't return focus on close
• ❌ Auto-playing media without controls
• ❌ Forms that only show errors in red (no text description)

Many of these are easy fixes once you know to look for them.

---

Wrapping Up

A11y testing doesn't have to be this massive, intimidating undertaking. Start small — drop jest-axe into one component test, run your page through Lighthouse, tab through your nav bar. You'll be surprised what you find, and you'll start building better habits from there.

The web is for everyone. As developers, we have more power than almost anyone to make that actually true. Accessibility testing is one of the most practical ways to act on that.

Key takeaways:

• Automated tools like axe-core and jest-axe make a11y testing approachable
• Automated tests only catch ~30-40% of issues — manual testing fills the gap
• Semantic HTML is your best friend and costs you nothing
• Bake a11y checks into your CI pipeline so you catch regressions early

Now go make something everyone can use. 🙌