axe-core Accessibility Testing: Examples and Results

Findings and manual review

axe-core is the open-source rules engine used by AllyProof alongside HTML_CodeSniffer and separate APCA advisory checks. Deque aims to avoid false positives, while acknowledging that software bugs can occur. This is a design policy, not a guarantee that every result from AllyProof's combined pipeline is correct.

Result	Interpretation
`violations`	A configured rule reported a failure.
`incomplete`	Manual review is needed.
`passes`	The specific rule check passed in the tested context.
`inapplicable`	No applicable elements were found.

Inspect the affected element, rule guidance, and page state when reviewing a finding. A scan covers the pages, states, and rules executed; a passing check does not establish conformance with an entire success criterion or website.

AllyProof combines inherited WCAG version tags rather than requesting only the latest additions. Best-practice and advisory results remain distinct from scored findings. Plan manual evaluation alongside automated scanning.

Run a check with Playwright

In a project with Playwright Test configured, install @axe-core/playwright as a development dependency. Save the example below as tests/accessibility.spec.ts, start your local website on port 3000, then run npx playwright test tests/accessibility.spec.ts.

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

test("homepage accessibility checks", async ({ page }) => {
  await page.goto("http://127.0.0.1:3000");
  const result = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"])
    .analyze();
  await test.info().attach("axe-results", {
    body: JSON.stringify(result, null, 2),
    contentType: "application/json",
  });
  expect(result.violations).toEqual([]);
});

This checks the rendered page in its current state. Open a menu or dialog before calling analyze() if that is the state you need to test. Run additional checks for other pages and important user journeys. The attached JSON keeps incomplete checks available for manual review even when the assertion passes.

From a finding to a verified fix

For each violation, use its rule ID and affected nodes to locate the component. Check the suggested repair against the actual interface, change the source, then rerun the same page and state. A missing form label, for example, needs an appropriate accessible name, not simply an empty aria-label added to silence a tool.

Our WordPress fix-and-recheck example and Webflow example show how to take a finding back to the editor. Combine this with keyboard testing and other manual checks.

When to use AllyProof alongside axe-core

Keep your own axe-core tests when you want checks in a development workflow. To inspect a public page without setting up test code, run a free accessibility scan. The preview uses AllyProof's combined scanning pipeline, so its results need not match this minimal axe-core example exactly.

For agencies maintaining client sites, website monitoring adds scheduled scans, issue history and shared follow-up. Compare plans when you need that ongoing workflow. Neither route replaces a complete accessibility evaluation.

Check these issues on your own website

Start with a free one-page preview, with no account or payment required. For scheduled scans, issue history and team workflows, explore paid monitoring.

Run a free accessibility scan Explore website monitoring