PlaywrightPHP

Accessibility

Use automated accessibility checks as fast guardrails beside semantic locators and manual review.

Accessibility checks help catch regressions that are easy to miss in visual testing: missing labels, invalid ARIA, contrast problems, missing document language, or broken semantic structure.

They are guardrails. They do not prove that the whole product is accessible.

Where to start

Run automated checks on a small set of representative pages:

  • home or landing page;
  • login and account pages;
  • one important form;
  • one data-heavy page;
  • one critical conversion or checkout step.

That catches broad regressions without turning the suite into an accessibility crawler.

Use semantic locators too

Accessibility starts before the audit. Tests that use roles, labels, and accessible names push the product toward better markup.

php
$page->getByRole('button', ['name' => 'Save changes'])->click();

expect($page->getByRole('status'))->toContainText('Saved');

If a control cannot be found by role or label, that is often a product signal, not just a test problem.

Exercise keyboard-critical flows

Automated rules cannot prove that a workflow works from the keyboard. Test critical paths through focus, keyboard actions, and visible state:

php
$page->getByLabel('Email')->fill('ada@example.com');
$page->getByLabel('Password')->fill('secret');
$page->getByLabel('Password')->press('Tab');

expect($page->getByRole('button', ['name' => 'Sign in']))
    ->toBeFocused();

Choose representative keyboard journeys rather than reproducing every pointer test.

Add automated audits deliberately

Use the accessibility companion package when you need axe-core checks from a Playwright PHP page. Scope audits to pages and components your team owns, publish the report, and document every excluded rule.

An automated audit catches known rule violations. It does not replace keyboard testing, screen-reader review, zoom checks, or feedback from disabled users.

Common pitfalls

  • Disabling rules without documenting why.
  • Excluding the failing component instead of fixing it.
  • Running the same audit on many pages with identical layout.
  • Ignoring keyboard navigation because axe passes.
  • Treating generated reports as a substitute for fixing violations.

Go next