Accessibility Testing: The Automated and Manual Approach That Actually Works

Accessibility is not a feature you ship once — it is a quality attribute you maintain continuously. Every new component, every redesign, every content update can introduce accessibility barriers. Without systematic testing, regressions creep in silently.

But here is the uncomfortable truth: automated accessibility tools only catch about 30% of real accessibility issues. The remaining 70% require human testing — keyboard navigation, screen reader evaluation, and cognitive assessment. You need both approaches.

Here is the combined testing strategy that works in practice without consuming your entire sprint.

Automated Testing: The Foundation

Automated tools check things machines can verify: missing alt text, insufficient color contrast, missing form labels, incorrect heading hierarchy, and ARIA attribute validity. These are the low-hanging fruit — easy to detect, easy to fix.

Our automated setup:

Build-time linting: eslint-plugin-jsx-a11y catches accessibility issues in JSX during development. Missing alt attributes, invalid ARIA props, and non-interactive elements with click handlers get flagged before the code is even committed.

Component testing: @testing-library/react with jest-axe. Every component test includes an accessibility assertion: expect(await axe(container)).toHaveNoViolations(). This catches issues in rendered output that static linting cannot detect.

Integration testing: axe-core integrated into Playwright end-to-end tests. After navigating to each page, run axe and assert no violations. This catches issues that emerge from component composition — individual components might pass but their combination might not.

CI pipeline: run all accessibility checks on every PR. Fail the build if new violations are introduced. This prevents regressions from shipping.

What Automated Tools Miss

Automated tools cannot evaluate: whether focus order is logical (they can check that elements are focusable, not that the order makes sense), whether screen reader announcements are helpful (they can check that ARIA attributes exist, not that they communicate useful information), whether interactive patterns are discoverable (can a user figure out how to use this without a mouse?), or whether content is understandable (cognitive accessibility).

These require human evaluation. Here is how to do it efficiently.

Manual Testing: Keyboard Navigation

Test every interactive flow using only the keyboard:

Tab through the entire page. Can you reach every interactive element (links, buttons, form inputs, menus)? Is the focus order logical (does it follow the visual layout, or does it jump unpredictably)?

Use Enter and Space to activate elements. Do buttons work with both? Do links work with Enter? Do custom components (dropdowns, modals, tabs) follow expected keyboard patterns?

Escape to dismiss overlays. When a modal is open, does Escape close it? Does focus return to the element that opened it?

Arrow keys for widget navigation. In a tab component, do left/right arrows move between tabs? In a dropdown, do up/down arrows navigate options?

Test focus trapping. When a modal is open, can Tab move focus outside the modal? It should not — focus should be trapped within the modal until it is dismissed.

We test keyboard navigation manually for every new component and every new page layout. It takes 5-10 minutes per page and catches issues that no automated tool detects.

Manual Testing: Screen Readers

Screen reader testing is the closest you get to experiencing your application as a blind user. It reveals whether your semantic HTML and ARIA attributes create a comprehensible experience.

Our testing setup: VoiceOver on macOS (free, built-in) for development testing. NVDA on Windows (free, open-source) for verification because most screen reader users use Windows.

What to test with a screen reader:

Page structure: does the screen reader announce headings, landmarks, and regions? Can a user navigate by headings to find the section they need? Does the page title make sense?

Form interaction: are labels associated with inputs? Does the screen reader announce required fields and validation errors? After submitting a form with errors, does focus move to the first error?

Dynamic content: when content updates without a page reload (notifications, live results, form feedback), does the screen reader announce the change? Use aria-live regions for important updates.

Images and media: do images have meaningful alt text (not "image123.png")? Are decorative images hidden (alt="" or role="presentation")? Do videos have captions?

Custom widgets: do custom components (accordions, tabs, tooltips) announce their state? Does a screen reader user know that a tab is selected, an accordion is expanded, or a tooltip is showing?

The 5-Minute Screen Reader Test

You do not need to test every page exhaustively. A focused 5-minute test catches most issues:

Open the page with VoiceOver (Cmd+F5 on Mac)

Press VO+A to read the entire page from top. Listen for: does it make sense? Is content in a logical order? Are important elements announced?

Navigate by headings (VO+Cmd+H). Do headings outline the page content clearly?

Tab through interactive elements. Are they announced with their role and state? ("Button: Submit form", "Link: View all tools")

Try the primary user flow. Can you complete the main task (search for a tool, submit a form, navigate to a category) without seeing the screen?

If any of these steps produce confusion or dead ends, there is an accessibility issue to fix.

Color and Visual Accessibility

Beyond automated contrast checking:

Test with simulated color blindness. Chrome DevTools can simulate protanopia, deuteranopia, and tritanopia. Information communicated only through color (red for error, green for success) is invisible to colorblind users.

Test at 200% zoom. WCAG requires that content is usable at 200% zoom. Does the layout break? Do elements overlap? Is text cut off? This also helps users with low vision who zoom their browsers.

Test with high contrast mode. Windows High Contrast Mode overrides your styles. Do interactive elements remain distinguishable? Do borders and focus indicators remain visible?

Respect prefers-reduced-motion. Users who set this preference are sensitive to animation. Disable or reduce animations when this media query matches.

Cognitive Accessibility

The hardest to test, often the most impactful:

Clear language: is error text understandable? "VALIDATION_ERR_422" is useless. "Please enter a valid email address" is clear.

Consistent navigation: does the same element appear in the same place on every page? Consistency reduces cognitive load.

Forgiving inputs: if a user enters a phone number as "555-123-4567" or "5551234567" or "(555) 123-4567", does the form accept all formats? Or does it demand a specific format without clear guidance?

Timeout warnings: if a session expires, does the user get a warning with option to extend? Abrupt session termination without warning is a major accessibility barrier for users who interact slowly.

Integrating Into Your Workflow

Do not try to do everything at once. Build accessibility testing incrementally:

Week 1: add eslint-plugin-jsx-a11y and fix all linting errors.

Week 2: add jest-axe to your component tests. Fix violations.

Week 3: add axe-core to your Playwright tests for critical pages.

Week 4: manually keyboard-test your 5 most important pages.

Week 5: screen reader test your 3 most important user flows.

After the initial investment, ongoing maintenance is: automated checks run in CI (zero effort), keyboard test new components during development (5 minutes each), screen reader test new features before release (15 minutes each).

This approach catches 90%+ of accessibility issues with about 30 minutes of manual testing per sprint — a reasonable investment for an inclusive product that serves all your users.