Accessibility Testing: Tools and a Checklist (WCAG 2.2)

Accessibility testing checks whether people with disabilities can use your software: someone navigating by keyboard alone, someone listening through a screen reader, someone zoomed to 400%, someone with low vision or a tremor. In the US the yardstick is the W3C’s Web Content Accessibility Guidelines (WCAG), and testing to WCAG 2.2 Level AA covers the older versions that Section 508 and the ADA rules point to. Do it in two layers: automated tools on every build, which catch a useful share of problems in seconds, and a short manual pass with a keyboard and a screen reader before each release, which catches the rest. Neither layer is enough alone.

What WCAG testing checks

WCAG 2.2↗ (opens in a new tab) became a W3C Recommendation on October 5, 2023. Its success criteria sit under four principles, often shortened to POUR: content must be perceivable, operable, understandable and robust. Each criterion has a level, A, AA or AAA, and Level AA is the usual target for laws and contracts. The W3C says content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, and it encourages using the latest version.

WCAG 2.2 added nine success criteria and removed one (4.1.1 Parsing, now obsolete). The new Level A and AA ones are where older test plans have gaps:

• 2.4.11 Focus Not Obscured (Minimum), AA: a focused control is not entirely hidden, for example under a sticky header or cookie banner.
• 2.5.7 Dragging Movements, AA: anything done by dragging also works with a single pointer, such as clicking.
• 2.5.8 Target Size (Minimum), AA: pointer targets are at least 24 by 24 CSS pixels, or spaced so they do not crowd each other.
• 3.2.6 Consistent Help, A: help links or contact details appear in the same relative place on every page.
• 3.3.7 Redundant Entry, A: people are not asked to retype what they already entered in the same process, such as a shipping address for billing.
• 3.3.8 Accessible Authentication (Minimum), AA: signing in does not depend on a memory or puzzle test without an alternative; letting password managers fill the field counts.

Section 508, the ADA, and which WCAG version applies

US rules cite different WCAG versions, which confuses many test plans. Here is what each primary source says, as of October 1, 2026. This is a summary for planning tests, not legal advice.

• Section 508 (federal agencies and what they buy): Section508.gov states that the Revised 508 Standards↗ (opens in a new tab) “incorporate by reference the WCAG 2.0 Level AA Success Criteria” and apply them to web and non-web electronic content. Federal testers use the DHS Trusted Tester process and the ICT Testing Baseline for consistent results.
• ADA Title II (state and local governments): the Justice Department’s web and mobile app rule↗ (opens in a new tab) adopts WCAG 2.1 Level AA. An interim final rule published April 20, 2026 extended the compliance dates to April 26, 2027 for entities serving 50,000 people or more, and April 26, 2028 for smaller ones and special districts.
• ADA Title III (businesses open to the public): there is no technical regulation. The Justice Department’s web accessibility guidance↗ (opens in a new tab), dated March 18, 2022, points businesses to WCAG and the Section 508 Standards as existing technical standards, and warns that “A ‘clean’ report does not necessarily mean everything is accessible.”

Because 2.2 includes everything in 2.1 and 2.0, one WCAG 2.2 AA test plan satisfies all three references. Test to the newest version and you will not have to redo the plan when a rule catches up.

Automated vs manual accessibility testing

Automated tools read the page’s code and rendered styles and flag what can be decided by rule: an image with no alt attribute, a form field with no label, text below the contrast ratio, a button with no accessible name, duplicate IDs. They are fast and cheap enough to run on every pull request. Their makers are candid about the limit: the axe-core README↗ (opens in a new tab) says “you can find on average 57% of WCAG issues automatically,” returns elements it cannot decide as “incomplete” for manual review, and claims zero false positives, bugs notwithstanding.

The rest needs a person, because it needs judgment. A tool can see that an image has alt text; only a person can tell that “image123.jpg” is useless. A tool can count headings; only a person can tell whether the order makes sense read aloud. The W3C’s guide to selecting evaluation tools↗ (opens in a new tab) states it directly: tools “can not determine accessibility, they can only assist in doing so.” Section508.gov’s testing guidance makes the same point about scanners, which is covered in the QA checklist.

Accessibility testing tools

• axe-core: the open-source rules engine from Deque. It has rules for WCAG 2.0, 2.1 and 2.2 at A, AA and AAA, plus best practices, and runs inside unit, component and end-to-end tests.
• Lighthouse: built into Chrome DevTools. Its accessibility score is a weighted average of pass-or-fail audits, weighted by axe’s impact ratings; Google’s documentation notes that the manual audits it lists do not affect the score, so a score of 100 still leaves the manual checks to do.
• Browser extensions and DevTools: accessibility tree inspectors and contrast pickers in Chrome, Edge, Firefox and Safari show what assistive technology will see.
• Screen readers: NVDA and JAWS on Windows, VoiceOver built into macOS and iOS, and TalkBack built into Android. Test with at least one desktop and one mobile reader your users are likely to have.
• Keyboard and zoom: no tool needed. Unplug the mouse, set browser zoom to 400% on a 1280-pixel-wide window, and use the product.

To run axe in your existing browser tests, Playwright documents the @axe-core/playwright package. Scoped to WCAG tags, a scan of the checkout page looks like this, and it slots into the suite described in end-to-end testing:

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

test('checkout has no detectable WCAG A/AA violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

An empty violations list means only that axe found nothing it can decide by rule. Treat it as the floor, not the finish.

The manual checks, step by step

1. Keyboard only. Tab through the whole journey: sign in, search, cart, checkout. Every control is reachable, works with Enter or Space, has a visible focus indicator that is never hidden under a banner, and nothing traps focus. Escape closes dialogs.
2. Screen reader. With NVDA or VoiceOver, move through the page by headings, then by form fields. Each field announces its label and whether it is required; errors are announced when they appear; buttons say what they do (“Remove desk lamp from cart”, not “Button”).
3. Zoom and reflow. At 400% zoom content reflows into one column without sideways scrolling, and with text enlarged to 200% nothing is cut off or overlaps.
4. Color and contrast. Normal text is at least 4.5:1 against its background, large text 3:1, and no information is shown by color alone: a red field border also has an error message.
5. Media and motion. Videos have captions, audio has a transcript, and anything that starts moving on its own and lasts more than five seconds can be paused.
6. Forms and sign-in. Password managers can fill and paste into the password field, and nothing makes the user retype an address they already gave.

An accessibility testing checklist to copy

PAGE / FLOW: ______________    BUILD: ______    TESTER: ______    DATE: ______

AUTOMATED (every pull request)
[ ] axe scan, tags wcag2a/wcag2aa/wcag21aa/wcag22aa: 0 violations
[ ] "incomplete" results reviewed by a person
[ ] Lighthouse accessibility audit run; listed manual checks noted

KEYBOARD
[ ] Every control reachable with Tab, in a logical order
[ ] Visible focus on every control; never fully hidden (2.4.11)
[ ] No keyboard trap; Escape closes dialogs and menus
[ ] Skip link to main content works

SCREEN READER (NVDA or JAWS + VoiceOver or TalkBack)
[ ] Page title and one h1 describe the page
[ ] Headings in order; landmarks for header, nav, main, footer
[ ] Images: meaningful alt text, or empty alt if decorative
[ ] Every form field announces its label and required state
[ ] Errors announced and explained in words
[ ] Buttons and links say what they do out of context

VISUAL
[ ] Text contrast 4.5:1 (large text 3:1); UI component contrast 3:1
[ ] No meaning carried by color alone
[ ] 400% zoom reflows to one column, no sideways scroll
[ ] Text at 200% not clipped or overlapping
[ ] Pointer targets at least 24 x 24 CSS px, or spaced (2.5.8)

INTERACTION
[ ] Drag actions have a single-pointer alternative (2.5.7)
[ ] Help or contact link in the same place on each page (3.2.6)
[ ] No re-entering information already given (3.3.7)
[ ] Sign-in allows paste and password managers (3.3.8)
[ ] Captions on video; pause control for moving content

RESULT: pass / fail    Bugs filed: ______    Not tested: ______

This list is the accessibility pass in depth. The release-day run that also covers browsers, security and speed is the QA checklist.

Who tests, and when

Developers run the automated scan locally and in CI, and fix what it flags before review; component-level checks belong beside unit tests. A tester or designer runs the manual pass on every new or changed flow before release. Once or twice a year, and before a major launch, test with people who use assistive technology every day; no checklist replaces watching a screen reader user try your checkout. Anything that breaks once goes on the regression testing checklist so it stays fixed. Which wider testing an accessibility pass sits beside is on the map in types of software testing.

Tracking accessibility issues on a board

fenbs does not scan pages; your tools and testers do. What it holds is the work that follows. File each failure as a task of kind bug, with the WCAG criterion, the page, the assistive technology and the steps in its note, and use priority 1-10 to put blockers such as a keyboard trap in checkout first. Mark the task’s test status Needs owner check when only a person with a screen reader can confirm the fix, and say in the test notes which reader and browser were used. If the team agrees that “every new form passes the keyboard check before review”, record it on the Decisions and rules page so every connected AI assistant reads it before writing UI code.