Alternate QA Hub
Back to Blog

Accessibility Testing: How to Ensure Your App Meets WCAG Standards

AlternateQA Team•
Accessibility is not just a legal compliance requirement — it's a quality dimension that makes your product better for everyone. Learn the practical techniques to test for WCAG 2.2 compliance and build accessibility into your QA process.

Why Accessibility Testing Belongs in QA

Over 1 billion people worldwide live with some form of disability. Accessibility barriers in software exclude these users from your product and, in many jurisdictions, expose your organization to legal liability (ADA in the USA, EAA in Europe, AODA in Canada).

But accessibility is not just about legal compliance. Every accessibility improvement makes your product better for all users. Captions benefit users watching video without sound. High color contrast helps users in bright sunlight. Keyboard navigation benefits power users who prefer not to use a mouse. Accessibility and usability are deeply intertwined.

QA engineers are often the last line of defense for accessibility issues. Making accessibility part of your standard testing process — not an afterthought — is the mark of a mature, professional QA team.

Understanding WCAG: The Four Principles

The Web Content Accessibility Guidelines (WCAG), currently at version 2.2, organize requirements around four core principles known by the acronym POUR:

1. Perceivable

Information must be presentable in ways all users can perceive.

  • Images must have alternative text (for screen readers)
  • Videos must have captions
  • Content must not rely on color alone to convey meaning
  • Text must have sufficient color contrast

2. Operable

UI components must be operable by all users.

  • All functionality must be available from the keyboard (no mouse required)
  • Users must have enough time to read and use content
  • Content must not cause seizures (no rapidly flashing elements)
  • Navigation must be clear and consistent

3. Understandable

Information and UI operation must be understandable.

  • Text must be readable (language is declared, unusual words are explained)
  • Pages must behave predictably
  • Error messages must clearly identify the problem and suggest solutions

4. Robust

Content must be robust enough for assistive technologies to interpret.

  • HTML must be valid and well-structured
  • Components must have correct ARIA roles, names, and states

WCAG defines three conformance levels: A (minimum), AA (standard target for most organizations), and AAA (highest, often aspirational).

Your Accessibility Testing Toolkit

1. Automated Scanning Tools

Automated tools catch approximately 30-40% of WCAG violations (the unambiguous, machine-detectable ones). Use them as a first pass, not the final word.

  • axe-core: The industry-standard accessibility testing engine. Available as a browser extension (axe DevTools), a Playwright/Cypress integration, and a Jest plugin.
  • Lighthouse: Built into Chrome DevTools. Run it from the "Lighthouse" tab in DevTools or via CLI: lighthouse https://myapp.com --preset=desktop --output=html
  • WAVE: A visual feedback tool (browser extension) that overlays accessibility errors directly on the page.

Integrating axe into Playwright:

import { checkA11y } from 'axe-playwright';

test('Dashboard page is accessible', async ({ page }) => {
  await page.goto('/dashboard');
  await checkA11y(page, null, {
    runOnly: ['wcag2a', 'wcag2aa'],
  });
});

2. Keyboard Navigation Testing

Close your mouse. Navigate your entire application using only the keyboard.

The keyboard testing checklist:

  • [ ] Tab moves focus forward through all interactive elements
  • [ ] Shift+Tab moves focus backward
  • [ ] Enter activates buttons and links
  • [ ] Space toggles checkboxes and activates buttons
  • [ ] Arrow keys navigate within widgets (dropdowns, menus, tabs, radio groups)
  • [ ] Escape closes modals and dropdowns, returning focus to the trigger
  • [ ] Focus is always visible (never invisible or lost)
  • [ ] Focus order is logical and follows reading order
  • [ ] Focus is trapped inside open modals (cannot Tab out to content behind the modal)

Focus trap bugs (where focus disappears or jumps unexpectedly) are among the most disorienting experiences for keyboard users. Test every modal, dropdown, and dialog carefully.

3. Screen Reader Testing

Screen readers are the primary interface for users with visual impairments. Testing with one is a humbling and illuminating experience.

Platform + Screen Reader combinations to test:

  • macOS / iOS: VoiceOver (built-in, activate with ⌘+F5 on Mac)
  • Windows: NVDA (free, open-source) or JAWS (enterprise standard)
  • Android: TalkBack (built-in)

What to check during screen reader testing:

  • Image alternative text reads meaningfully (not "image001.png")
  • Form fields are properly labeled (not just visually labeled)
  • Interactive elements announce their role and state ("collapsed" for an accordion, "checked" for a checkbox)
  • Error messages are announced when form validation fails
  • Dynamic content updates (notifications, loading states, live regions) are announced
  • Custom components (date pickers, sliders, carousels) behave as expected

4. Color Contrast Testing

Use the eyedropper tool in browser DevTools or a dedicated tool like the Colour Contrast Analyser to check:

  • Normal text: 4.5:1 contrast ratio minimum (WCAG AA)
  • Large text (18pt+ or 14pt+ bold): 3:1 contrast ratio minimum
  • UI components and graphics: 3:1 contrast ratio minimum

Don't rely on memory or visual estimation. Measure it.

Building Accessibility into Your Process

Definition of Done

Add accessibility criteria to your team's Definition of Done:

  • [ ] Automated axe scan passes (zero WCAG AA violations)
  • [ ] Keyboard navigation verified
  • [ ] Color contrast checked for all new UI elements
  • [ ] New images have meaningful alt text

Accessibility in Code Review

QA engineers can add accessibility checks to the code review process:

  • Is alt attribute present and meaningful on all <img> tags?
  • Are form <input> elements associated with <label> elements?
  • Are custom interactive elements using correct ARIA roles?
  • Does the component use semantic HTML where possible?

Shift-Left: Catch Issues in Design

The cheapest time to fix an accessibility issue is in the design phase. Designers should:

  • Verify contrast ratios in Figma (use the Contrast plugin)
  • Annotate mockups with focus order and ARIA labels
  • Use established accessible component patterns (not novel, inaccessible widgets)

Common High-Impact Issues to Look For

  1. Images without alt text: A decorator image should have alt="" (empty, not missing). Informational images need descriptive alt text.
  2. Form fields without labels: A placeholder is not a label. It disappears when you type.
  3. Low color contrast: Very common in "trendy" designs with light grey text on white backgrounds.
  4. Keyboard traps: Focus enters a component and cannot exit with the keyboard.
  5. Missing focus indicators: Removing the browser's default focus ring without replacing it is a WCAG violation.
  6. Dynamic content that doesn't announce: A success toast notification that only appears visually but isn't announced to screen reader users.
  7. Icon buttons without accessible names: A button with only a hamburger menu icon and no text or aria-label is inaccessible.

Accessibility testing is a journey. Start with automated scanning to eliminate the easy wins, then add keyboard testing to your standard test runs. Schedule a manual screen reader testing session quarterly. Each improvement you make expands your product's reach and demonstrates genuine care for all of your users.