What is accessibility testing?

What is accessibility testing?

Accessibility testing is a type of non-functional software testing that checks whether people with disabilities can use a website or app. It combines automated scans of the page code with manual checks, e.g. completing a task with a keyboard alone. When the checks follow the Web Content Accessibility Guidelines (WCAG), it is often called WCAG testing.

The International Software Testing Qualifications Board (ISTQB) defines accessibility as how far people with the widest range of characteristics and capabilities can use a system to reach a goal. Many people with disabilities use assistive technology, e.g. a screen reader that reads the page aloud.

WCAG 2.2, from the World Wide Web Consortium (W3C), writes its success criteria as testable statements under four principles, often shortened to POUR. Content must be perceivable, operable, and understandable, and the fourth principle requires that it work with browsers and assistive technology. Each criterion has a level of A, AA, or AAA.

Level A is the minimum. Many laws point to level AA, e.g. the US Section 508 standards, which require WCAG 2.0 levels A and AA for federal agencies' public content and software. The W3C does not recommend requiring level AAA for whole sites, because some content cannot meet it. The W3C's WCAG overview states that content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0.

How does accessibility testing work?

An accessibility test of a web app usually runs in five steps:

1. The team chooses a standard and a level to test against, e.g. WCAG 2.2 level AA.
2. An automated scan loads each page in a browser, often a headless browser, and checks its elements and styles against rules.
3. A tester completes each task with a keyboard alone. Tab must reach each control or group in a sensible order with visible focus, and the expected key must operate it, e.g. Space on a checkbox.
4. A tester repeats the tasks with a screen reader. The screen reader should announce each control's name and role, and any state it has, and headings should let the listener jump through the page.
5. The team logs each failure against the WCAG criterion it breaks, then retests after the fix.

A screen reader reads the page through the browser's accessibility tree, not its pixels. A control that looks right on screen can still have no name, or no place, in that tree.

Accessibility testing tools fall into four groups:

• Rule checkers. A rule checker runs rules against a rendered page and lists each violation.
• Linters. An accessibility linter checks source code before it runs, e.g. eslint-plugin-jsx-a11y, whose no-static-element-interactions rule flags a click handler on a div.
• Screen readers. Most operating systems include a screen reader, e.g. VoiceOver on macOS. On Windows, NVDA is a free, open-source one.
• Browser developer tools. Most browsers' developer tools show each element's computed name and role.

Scans are a form of test automation, so a continuous integration and delivery (CI/CD) pipeline can run them on each change. A browser test framework, e.g. Playwright, can run an open-source accessibility checker inside a test, as Playwright's accessibility testing guide shows. Manual checks take a person's time, so teams usually run them on changed tasks and before release.

What is an example of an accessibility check?

Here is an illustrative example. Acme Co. sells furniture online. A developer asks a coding agent to "Let customers edit their delivery address during checkout." The change goes through seven steps:

1. The agent adds a pencil icon next to the address, drawn as an inline SVG inside a div with a click handler.
2. The agent's browser test clicks the icon by its test ID, edit-address, and passes.
3. An automated scan of the checkout page lists 0 violations, because it cannot detect the click handler on the div.
4. A tester at Acme presses Tab through checkout. Focus moves from the "Back to cart" link to the "Place order" button and skips the icon.
5. With a screen reader on, the tester finds no button for editing the address.
6. The agent replaces the div with a button named "Edit delivery address."
7. The developer adds a keyboard check to the browser test.

The fix changes the markup:

- <div className="edit-icon" data-testid="edit-address"
-   onClick={openAddressForm}>
-   <PencilIcon />
- </div>
+ <button type="button" data-testid="edit-address"
+   aria-label="Edit delivery address" onClick={openAddressForm}>
+   <PencilIcon aria-hidden="true" />
+ </button>

The keyboard check finds the control by its role and accessible name, the same data a screen reader announces:

import { test, expect } from "@playwright/test";

test("customer edits the delivery address by keyboard", async ({ page }) => {
  await page.goto("https://shop.example.com/checkout");
  await page.getByRole("link", { name: "Back to cart" }).focus();
  await page.keyboard.press("Tab");
  const edit = page.getByRole("button", { name: "Edit delivery address" });
  await expect(edit).toBeFocused();
  await page.keyboard.press("Enter");
  const address = page.getByRole("textbox", { name: "Delivery address" });
  await expect(address).toBeVisible();
});

On the old markup, the check fails at toBeFocused, because no element has the button role and that name. With the fix, it passes. This example is simplified. A real checkout would need more checks, e.g. that a screen reader announces an error for an empty address.

What changes when a coding agent writes the code?

The Acme request says nothing about keyboards or screen readers, so neither the agent's code nor its test covers them. Asked later to make the icon accessible, an agent can add role="button" and an aria-label to the div. A role locator then finds the icon, but a role adds no keyboard behavior, so Tab still skips it and the keyboard check still fails at toBeFocused. The linter's interactive-supports-focus rule flags that half fix.

Browser automation that an agent drives often reads a text snapshot of the accessibility tree. In that snapshot the Acme icon has no name, the same gap a screen reader user meets. A computer-use agent reads screenshots and clicks by position, so it can click the icon and finish a task that a keyboard user cannot.

The prompt can ask for keyboard access and a name for each control, and a test can reach each control with Tab. A reviewer can spot a click handler on a div in a diff, but not what a screen reader announces. So the Learning Center's code review checklist leaves accessibility to the keyboard and screen reader checks above.

What do automated accessibility scans miss?

An automated scan checks rules that a program can decide from the page, and many success criteria need a person's judgment. Playwright's guide says automated tests "can detect some common accessibility problems," but that many problems "can only be discovered through manual testing." The table splits common checks between a scan and a person:

A scan also checks only the page states it loads. A form error that appears after a click stays unchecked unless a test triggers it. That is one reason to run scans inside end-to-end tests and user journey tests.

A scan with no findings does not show a page is accessible. The W3C's evaluation resources state that no tool alone can determine whether a site meets accessibility standards.

How is accessibility testing different from usability testing?

Usability testing measures how well specified users reach their goals, by effectiveness, efficiency, and satisfaction. Testers usually watch people try tasks and note where they struggle. Accessibility testing asks whether people with disabilities can complete those tasks at all, usually against the success criteria in WCAG.

The two overlap. A usability study that includes people who use assistive technology tests both at once, and a manual screen reader session often runs as exploratory testing. A page can meet WCAG level AA and still be hard to use with a screen reader, so neither result stands in for the other.

FAQs

What is WCAG?

WCAG, the Web Content Accessibility Guidelines, is the W3C standard that web accessibility testing usually checks against. Its testable success criteria sit under four principles, and each criterion has a level of A, AA, or AAA.

Which WCAG level should a website meet?

A website usually targets WCAG level AA, the level that many accessibility laws point to. A law can name an older version, e.g. the US Section 508 standards require WCAG 2.0, so a team checks which version applies. The W3C does not recommend level AAA as a requirement for a whole site.

How do you test a page with a screen reader?

Testing a page with a screen reader means turning the screen reader on and completing each task with the keyboard alone. Listen for each control's name and role, and any state it has, and check that the headings let you jump through the page.

Who should test a site for accessibility?

Testing a site for accessibility is usually shared across a team. Developers run automated scans and keyboard checks on each change. Testers check each task with a screen reader, and people with disabilities show whether the site works with the assistive technology they use.