AxeCore Playwright in Practice

Accessibility is no longer a checkbox item or something teams worry about just before an audit. For modern digital products, especially those serving enterprises, governments, or regulated industries, accessibility has become a legal obligation, a usability requirement, and a business risk factor. At the same time, development teams are shipping faster than ever. Manual accessibility testing alone cannot keep up with weekly or even daily releases. This is where AxeCore Playwright enters the picture. By combining Playwright, a modern browser automation tool, with axe-core, a widely trusted WCAG rules engine, teams can integrate accessibility checks directly into their existing test pipelines.

But here is the truth that often gets lost in tool-centric discussions: Automation improves accessibility only when its limitations are clearly understood.This blog walks through a real AxeCore Playwright setup, explains what the automation actually validates, analyzes a real accessibility report, and shows how this approach aligns with government accessibility regulations worldwide without pretending automation can replace human testing.

Why AxeCore Playwright Fits Real Development Workflows

Many accessibility tools fail not because they are inaccurate, but because they do not fit naturally into day-to-day engineering work. AxeCore Playwright succeeds largely because it feels like an extension of what teams are already doing.

Playwright is built for modern web applications. It handles JavaScript-heavy pages, dynamic content, and cross-browser behavior reliably. Axe-core complements this by applying well-researched, WCAG-mapped rules to the DOM at runtime.

Together, they allow teams to catch accessibility issues:

• Early in development, not at the end
• Automatically, without separate test suites
• Repeatedly, to prevent regressions

This makes AxeCore Playwright especially effective for shift-left accessibility, where issues are identified while code is still being written, not after users complain or audits fail.

At the same time, it’s important to recognize that this combination focuses on technical correctness, not user experience. That distinction shapes everything that follows.

The Accessibility Automation Stack Used

The real-world setup used in this project is intentionally simple and production-friendly. It includes Playwright for browser automation, axe-core as the accessibility rule engine, and axe-html-reporter to convert raw results into readable HTML reports.

The accessibility scope is limited to WCAG 2.0 and WCAG 2.1, Levels A and AA, which is important because these are the levels referenced by most government regulations worldwide.

This stack works extremely well for:

• Detecting common WCAG violations
• Preventing accessibility regressions
• Providing developers with fast feedback
• Generating evidence for audits

However, it is not designed to validate how a real user experiences the interface with a screen reader, keyboard, or other assistive technologies. That boundary is deliberate and unavoidable.

Sample AxeCore Playwright Code From a Real Project

One of the biggest advantages of AxeCore Playwright is that accessibility tests do not live in isolation. They sit alongside functional tests and reuse the same architecture.

Page Object Model With Accessible Selectors

import { Page, Locator } from "@playwright/test";

export class HomePage {
  readonly servicesMenu: Locator;
  readonly industriesMenu: Locator;

  constructor(page: Page) {
    this.servicesMenu = page.getByRole("link", { name: "Services" });
    this.industriesMenu = page.getByRole("link", { name: "Industries" });
  }
}

This approach matters more than it appears at first glance. By using getByRole() instead of CSS selectors or XPath, the automation relies on semantic roles and accessible names. These are the same signals used by screen readers.

As a result, test code quietly encourages better accessibility practices across the application. At the same time, it’s important to be realistic: automation can confirm that a role and label exist, but it cannot judge whether those labels make sense when read aloud.

Configuring axe-core for Meaningful WCAG Results

One of the most common reasons accessibility automation fails inside teams is noisy output. When reports contain hundreds of low-value warnings, developers stop paying attention.

This setup avoids that problem by explicitly filtering axe-core rules to WCAG-only checks:

import AxeBuilder from "@axe-core/playwright";

const makeAxeBuilder = (page) =>
  new AxeBuilder({ page }).withTags([
    "wcag2a",
    "wcag2aa",
    "wcag21a",
    "wcag21aa",
  ]);

By doing this, the scan focuses only on the success criteria recognized by government and regulatory bodies. Experimental or advisory rules are excluded, which keeps reports focused and credible.

For CI/CD pipelines, this focus is essential. Accessibility automation must produce clear signals, not noise.

Running the Accessibility Scan: What Happens Behind the Scenes

Executing the scan is straightforward:

const accessibilityScanResults = await makeAxeBuilder(page).analyze();

When this runs, axe-core parses the DOM, applies WCAG rule logic, and produces a structured JSON result. It evaluates things like color contrast, form labels, ARIA usage, and document structure.

What it does not do is equally important. The scan does not simulate keyboard navigation, does not listen to screen reader output, and does not assess whether the interface is intuitive or understandable. It evaluates rules, not experiences.

Understanding this distinction prevents false assumptions about compliance.

Generating a Human-Readable Accessibility Report

The raw results are converted into an HTML report using axe-html-reporter. This step is critical because accessibility should not live only in JSON files or CI logs.

HTML reports allow:

• Developers can quickly see what failed and why
• Product managers need to understand severity and impact
• Auditors to review evidence without technical context

This is where accessibility stops being “just QA work” and becomes a shared responsibility.

What the Real Accessibility Report Shows

The uploaded report covers the Codoid homepage and provides a realistic snapshot of what accessibility automation finds in practice.

At a high level, the scan detected two violations, both marked as serious, while passing 29 checks and flagging several checks as incomplete. This balance is typical for mature but not perfect applications.

The key takeaway here is not the number of issues, but the type of issues automation is good at detecting.

Serious WCAG Violation: Color Contrast (1.4.3)

Both violations in the report relate to insufficient color contrast in testimonial text elements. The affected text appears visually subtle, but the contrast ratio measured by axe-core is 3.54:1, which falls below the WCAG AA requirement of 4.5:1.

This kind of issue directly affects users with low vision or color blindness and can make content difficult to read in certain environments. Because contrast ratios are mathematically measurable, automation excels at catching these problems.

In this case, AxeCore Playwright:

• Identified the exact DOM elements
• Calculated precise contrast ratios
• Provided clear remediation guidance

This is exactly the type of accessibility issue that should be caught automatically and early.

Passed and Incomplete Checks: Reading Between the Lines

The report also shows 29 passed checks, covering areas such as ARIA attributes, image alt text, form labels, document language, and structural keyboard requirements. These passes are quite successful in preventing regressions over time.

At the same time, 21 checks were marked as incomplete, primarily related to color contrast under dynamic conditions. Axe-core flags checks as incomplete when it cannot confidently evaluate them due to styling changes, overlays, or contextual factors.

This honesty is a strength. Instead of guessing, the tool clearly signals where manual testing is required.

Where AxeCore Playwright Stops and Humans Must Take Over

Even with a clean report, accessibility can still fail real users. This is where teams must resist the temptation to treat automation results as final.

Automation cannot validate how a screen reader announces content or whether that announcement makes sense. It cannot determine whether the reading order feels logical or whether keyboard navigation feels intuitive. It also cannot assess cognitive accessibility, such as whether instructions are clear or error messages are understandable.

In practice, accessibility automation answers the question:
“Does this meet the technical rules?”

Manual testing answers a different question:
“Can a real person actually use this?”

Both are necessary.

Government Accessibility Compliance: How This Fits Legally

Most government regulations worldwide reference WCAG 2.1 Level AA as the technical standard for digital accessibility.

In the United States, ADA-related cases consistently point to WCAG 2.1 AA as the expected benchmark, while Section 508 explicitly mandates WCAG 2.0 AA for federal systems. The European Union’s EN 301 549 standard, the UK Public Sector Accessibility Regulations, Canada’s Accessible Canada Act, and Australia’s DDA all align closely with WCAG 2.1 AA.

AxeCore Playwright supports these regulations by:

• Automatically validating WCAG-mapped technical criteria
• Providing repeatable, documented evidence
• Supporting continuous monitoring through CI/CD

However, no government accepts automation-only compliance. Manual testing with assistive technologies is still required to demonstrate real accessibility.

The Compliance Reality Most Teams Miss

Government regulations do not require zero automated violations. What they require is a reasonable, documented effort to identify and remove accessibility barriers.

AxeCore Playwright provides strong technical evidence. Manual testing provides experiential validation. Together, they form a defensible, audit-ready accessibility strategy.

Final Thoughts: Accessibility Automation With Integrity

AxeCore Playwright is one of the most effective tools available for scaling accessibility testing in modern development environments. The real report demonstrates its value clearly: precise findings, meaningful coverage, and honest limitations. The teams that succeed with accessibility are not the ones chasing perfect automation scores. They are the ones who understand where automation ends, where humans add value, and how to combine both into a sustainable process. Accessibility done right is not about tools alone. It’s about removing real barriers for real users and being able to prove it.

Frequently Asked Questions

Ensure your application aligns with WCAG, ADA, Section 508, and global accessibility regulations without slowing down releases.

Talk to an Accessibility Expert