Accessibility Testing You Can Run Today

Contributor
Mar 23
5 min read

Accessibility (a11y) testing has a reputation for being specialized — something the accessibility team does, or that you bring in consultants for. The reality: about 30% of accessibility issues can be caught by automated tools that take minutes to run. Another 40% can be caught by basic keyboard testing and screen reader spot checks. The remaining 30% requires expertise.

This guide is what every developer can do today.

The Quick Wins

The fastest accessibility wins:

Run axe-core or Lighthouse on your pages
Test keyboard navigation
Test with the OS-native screen reader briefly
Verify color contrast
Check that all images have alt text
Check that forms have labels

Each takes minutes. Each catches issues that affect real users.

Automated Tools

The mature ones:

axe-core: library that scans pages for WCAG violations. Free, well-maintained.
Lighthouse: built into Chrome DevTools. Quick audit including accessibility.
WAVE: browser extension; visual highlighting of issues.
Pa11y: CLI tool, good for CI integration.

What they catch:

Missing alt text on images
Form inputs without labels
Low contrast text
Missing ARIA attributes
Heading hierarchy issues
Missing language attribute
Empty links and buttons

What they miss:

Whether the alt text is meaningful
Whether focus order makes sense
Whether interactive elements actually work with keyboard
Whether screen readers can navigate the page
Whether dynamic content is announced

In CI

Integrating axe into CI:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage has no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

This catches regressions automatically. New violations show up immediately.

A working pattern: zero new violations allowed; existing violations tracked for cleanup.

Manual Keyboard Testing

Disconnect your mouse. Navigate your site with only the keyboard.

Tab: moves to next interactive element
Shift+Tab: moves to previous
Enter: activates buttons and links
Space: activates buttons; toggles checkboxes
Arrow keys: navigate within menus, sliders, etc.

Verify:

Every interactive element is reachable
Focus is visible at all times
Focus order makes sense (typically top-to-bottom, left-to-right)
Modals trap focus
Escape closes modals
No keyboard traps (can't escape an element)

If you can't use the site with keyboard alone, neither can many users.

Screen Reader Spot-Check

You don't need to be a screen reader expert. A quick spot-check:

macOS: VoiceOver (Cmd+F5)
Windows: Narrator (Windows+Ctrl+Enter) or NVDA (free download)
iOS: VoiceOver
Android: TalkBack

Navigate a key flow on your site. Listen.

Are headings announced as headings?
Are buttons described meaningfully ("Save" vs. "Button")?
Are images described or marked decorative?
Does the screen reader say something useful at each step?

Even 10 minutes of screen reader use reveals issues that automated tools don't catch.

Color Contrast

WCAG specifies minimum contrast ratios:

4.5:1 for normal text
3:1 for large text (18pt+ or 14pt bold+)
3:1 for UI components and graphical objects

Tools to check:

Browser DevTools (built into Chrome, Firefox)
WebAIM Contrast Checker
Stark (design tool plugin)

Common failures:

Light gray text on white background
Placeholder text in form inputs
Disabled state styling
Brand colors used for text

Don't rely on screenshots; check the actual colors used.

Headings

Headings should describe the page structure.

One <h1> per page (the main title)
Headings in order: don't skip levels (h1 → h2 → h3, not h1 → h3)
Headings describe sections meaningfully

Screen reader users navigate by heading. If your headings are scattered or just visual decoration, navigation breaks.

Forms

Form accessibility:

Every input has a <label> associated with it
Required fields are marked accessibly (not just with a red asterisk)
Error messages are associated with their inputs
Errors are announced to screen readers (often via aria-live)

A common failure: visual-only error indication. The user with low vision sees the red highlight; the screen reader user sees nothing.

Images

Three categories:

Informative: has meaningful content. Needs alt text describing the content.
Decorative: purely visual, no information. Should have empty alt (alt="").
Functional: part of an interaction (button icon, link). Alt describes the action.

The mistake: alt text that describes what the image is (file format, generic description) instead of what it conveys. "Photograph of woman smiling" is worse than "Customer satisfaction" for a marketing graphic.

ARIA: Use Sparingly

ARIA (Accessible Rich Internet Applications) attributes provide semantic information for screen readers.

Rule: native HTML elements with built-in semantics are preferred. ARIA fills gaps.

<button> is better than <div role="button">
<a href> is better than <div onclick role="link">
Native <input type="checkbox"> is better than custom checkbox

When you use ARIA, use it correctly. Wrong ARIA is worse than no ARIA because it lies to assistive technologies.

Dynamic Content

Single-page apps have unique accessibility considerations:

Route changes should be announced (or focus moved to new content)
Loading states should be communicated
Modals should manage focus correctly
Toasts and notifications should reach screen readers

aria-live regions can announce dynamic content. Use sparingly; overuse is annoying.

Tooling for Different Roles

Developers: axe in CI, manual keyboard testing
Designers: Stark or similar in design tools, contrast checking
QA: WAVE or browser extensions, screen reader spot-checks
Product: awareness of WCAG categories, user research with people with disabilities

The full a11y picture isn't one role. Each role has tools that fit.

When to Bring In Specialists

DIY testing catches a lot but not everything. Specialist help is valuable for:

WCAG conformance audits
Complex interactions (custom widgets, drag-and-drop)
User research with people with disabilities
Remediating existing accessibility debt
Compliance for regulated contexts

The combination of internal testing and periodic specialist review covers more than either alone.

What WCAG Means

WCAG (Web Content Accessibility Guidelines) is the standard. Levels:

A: minimum
AA: typical target for products
AAA: maximum; few products achieve

Most accessibility commitments target AA. Some specific requirements (legal contexts) require AAA.

Each guideline has success criteria. Tools and manual testing verify whether criteria are met.

Anti-Patterns

Testing accessibility once at launch. Issues accumulate post-launch. Continuous matters.

Treating it as a checklist. "All images have alt text" doesn't mean the alt text is useful.

Tooling without manual testing. Tools catch ~30% of issues. The rest needs human judgment.

Accessibility as separate initiative. When it's separated from development, it falls behind. Integrate it.

Mock screen reader experience. Reading the code and imagining the experience. Use a real screen reader.

A Minimum Investment

If you have nothing today:

Add axe to your CI for at least one critical page
Spend an hour navigating your site with keyboard only
Spend 30 minutes with a screen reader on a key flow
Add contrast checks to your design review
Fix the obvious issues found

That's a day of work. It improves your accessibility significantly without bringing in specialists.

Key Takeaway

Accessibility testing isn't only for specialists. Automated tools (axe, Lighthouse) catch ~30% of issues quickly. Manual keyboard and screen reader testing catches another ~40%. The remaining ~30% requires expertise. Run axe in CI; do periodic manual checks; bring in specialists for complex products or compliance contexts. Treat accessibility as a continuous practice integrated with development, not a launch-time checkbox.

ShiftQuality