accessibility-verification

Frontend Accessibility Verification

Overview

Accessibility testing ensures UI is usable by everyone, including users with disabilities. It's both a legal requirement (WCAG compliance) and fundamental to good UX.

When to use this skill:

• Implementing any UI component
• Modifying existing UI
• Before marking UI work complete
• During code review (verify accessibility tested)

The Iron Law

NO UI SHIP WITHOUT ACCESSIBILITY VERIFICATION

If you created or modified UI:

• You MUST run automated accessibility tests (axe-core)
• You MUST test keyboard navigation
• You MUST verify screen reader announcements
• You CANNOT claim "UI complete" without accessibility evidence

Why Accessibility Matters

Legal requirement:

• WCAG 2.1 Level AA compliance mandatory in many industries
• ADA lawsuits for inaccessible websites
• Section 508 compliance for government contracts

Better UX for everyone:

• Accessible sites work better for all users
• Many a11y issues are actual bugs (missing labels, broken keyboard nav)
• If button has no accessible name, it's both unusable AND untestable

Automated testing catches ~57% of issues:

• axe-core finds definite violations (zero false positives)
• Manual testing required for remaining ~43%
• Both automated AND manual testing necessary

Step-by-Step Process

Step 1: Automated Testing (axe-core)

Run axe-core on all UI components:

Playwright Integration

import { injectAxe, checkA11y } from 'axe-playwright';

test('component is accessible', async ({ page }) => {
  await page.goto('/checkout');

  // Inject axe-core into page
  await injectAxe(page);

  // Run accessibility audit
  await checkA11y(page, null, {
    detailedReport: true,
    detailedReportOptions: {
      html: true,
    },
  });
});

Cypress Integration

import 'cypress-axe';

describe('Accessibility', () => {
  it('has no a11y violations', () => {
    cy.visit('/checkout');
    cy.injectAxe();
    cy.checkA11y();
  });
});