Accessibility Checks

Automated accessibility scans

The open-source axe-core engine detects many WCAG problems automatically: missing labels, insufficient colour contrast, invalid ARIA, missing alt text. In Playwright, the @axe-core/playwright package provides AxeBuilder: scan the page (optionally limited with include, exclude or withTags) and assert that violations is empty. In Cypress, the community cypress-axe plugin adds cy.injectAxe() and cy.checkA11y(). Automated scans catch only part of accessibility issues; keyboard navigation and screen-reader checks still need manual testing. Role-based locators help too: if getByRole cannot find your button, assistive technology may struggle as well.

Scanning a page in both tools

Playwright with AxeBuilder; Cypress with cypress-axe.

// Playwright: npm i -D @axe-core/playwright
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('signup page has no detectable WCAG A/AA violations', async ({ page }) => {
  await page.goto('/signup');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .exclude('#third-party-chat')
    .analyze();
  expect(results.violations).toEqual([]);
});

// Cypress: npm i -D cypress-axe axe-core, then import 'cypress-axe' in the support file
it('signup page has no detectable violations', () => {
  cy.visit('/signup');
  cy.injectAxe();
  cy.checkA11y();
});

A spell checker for accessibility

axe is like a spell checker: it reliably flags many mistakes, but it cannot tell you whether the essay makes sense to a reader.

Quick check: What is a limitation of automated accessibility scans?

• They only work in Firefox
• They catch only a portion of issues; manual keyboard and screen-reader testing is still needed
• They require a paid licence
• They cannot run inside E2E tests