# Accessibility testing with coding agents

> Accessibility testing with coding agents combines deterministic scans, keyboard flows, semantic inspection, and human review. Build useful evidence into every UI change.

URL: https://factory.com/articles/accessibility-testing-coding-agents
Published: 2026-09-24
Updated: 2026-09-24

Accessibility testing with coding agents works best as a layered review. Static rules can catch missing labels and invalid relationships. Browser automation can exercise keyboard flows and inspect the accessibility tree. Human evaluation still matters for meaning, usability, and assistive-technology behavior that automated checks cannot judge reliably.

The W3C Web Accessibility Initiative explains that [evaluation tools can assist review](https://www.w3.org/WAI/test-evaluate/tools/selecting/), but no tool can determine accessibility on its own. A coding agent should gather repeatable evidence and fix clear defects without turning a clean scanner result into a broad compliance claim.

## Turn accessibility requirements into testable behavior

Start with the affected user flow and the relevant [WCAG 2.2](https://www.w3.org/TR/WCAG22/) success criteria. Translate each requirement into an observable check.

A dialog should receive focus when it opens, keep keyboard focus inside while active, expose its name and role, close with Escape when appropriate, and return focus to the control that opened it.

Include viewport, browser, theme, input method, and authentication state in the task. Name the components and routes in scope. Ask the agent to preserve product behavior and visual intent while changing semantics.

Broad instructions such as "make the page accessible" invite unrelated edits and provide no finish line.

Use repository guidance to define the approved component system and validation commands. Factory's [AGENTS.md support](https://docs.factory.com/harness/agents-md) lets teams keep those rules close to the code, including directory-specific instructions and required checks.

## Combine code checks with browser evidence

Run the project's accessibility linter and deterministic browser scanner first. These checks are fast and produce stable findings. Review each result in context because hidden content, custom widgets, and application state can affect whether a rule applies. Then drive the critical path using only the keyboard. Check focus order, visible focus, skip links, menus, dialogs, error recovery, and dynamic updates. Inspect names, roles, states, and relationships in the accessibility tree. Resize or zoom the page when layout changes could obscure controls or cause content loss.

Factory's [Automated QA](https://docs.factory.com/software-factory/automated-qa) uses an isolated browser to navigate flows, capture accessibility-tree snapshots, and produce screenshots as review evidence. Scope the run from the code diff so a small component change does not trigger an unfocused crawl of the entire product.

## Separate fixes from compliance decisions

The coding agent can repair deterministic defects such as an unlabeled input, broken heading order, missing focus management, or a control implemented with the wrong element. It should avoid guessing at alternative text, reading order, or interaction intent when product context is missing.

Those cases need a designer, content owner, or accessibility specialist.

Record the route, starting state, interaction steps, expected result, actual result, and captured evidence. Include the exact scanner and version used. If a check is blocked by authentication, test data, or an unavailable assistive technology, mark it blocked rather than passed.

Keep review independent. The same agent may implement and run deterministic checks, but a reviewer should inspect the evidence and sample the changed flow. For recurring coverage, Factory [Custom Automations](https://docs.factory.com/software-factory/automations) can launch QA from a GitHub event or schedule.

Human testing remains part of the release process for high-impact journeys.

## Frequently asked questions

### How should coding agents test accessibility?

Use a layered review. Static rules catch missing labels and invalid relationships, browser automation exercises keyboard flows and inspects the accessibility tree, and a human reviewer checks the evidence and samples the changed flow.

### Can an accessibility scanner prove a page is accessible?

No. The W3C Web Accessibility Initiative explains that evaluation tools can assist review, but no tool can determine accessibility on its own. A clean scanner result should not become a broad compliance claim.

### Which accessibility fixes should an agent leave to people?

The agent can repair deterministic defects such as an unlabeled input, broken heading order, or missing focus management. Alternative text, reading order, and interaction intent need a designer, content owner, or accessibility specialist when product context is missing.

### How does Factory help with accessibility testing?

Factory Automated QA uses an isolated browser to navigate flows, capture accessibility-tree snapshots, and produce screenshots as review evidence. Custom Automations can launch QA from a GitHub event or schedule.

## Further reading

- [Finding the cause of flaky tests with coding agents](https://factory.com/articles/flaky-test-triage-coding-agents)
- [Automated QA](https://docs.factory.com/software-factory/automated-qa)
- [W3C accessibility evaluation overview](https://www.w3.org/WAI/test-evaluate/)
- [WCAG 2.2](https://www.w3.org/TR/WCAG22/)