Skip to content

SHIFT_LEFT_ACCESSIBILITY_AUTOMATION.md

Latest commit

 

History

History
62 lines (40 loc) · 2 KB

SHIFT_LEFT_ACCESSIBILITY_AUTOMATION.md

File metadata and controls

62 lines (40 loc) · 2 KB
title Shift-Left Accessibility Automation

Shift-Left Accessibility Automation

This guide focuses on preventing accessibility issues from entering commits in the first place.

Core principle

Catch issues as early as possible:

  1. In-editor and local linting
  2. Pre-commit checks
  3. Pull request CI gates
  4. Scheduled full-site scans

1) Local developer checks

Minimum local checks before commit:

  • Accessibility-focused lint rules (framework-specific where applicable).
  • Unit/component accessibility checks (for UI components).
  • Fast smoke checks for obvious violations.

2) Pre-commit gate (recommended)

Run accessibility checks only on changed files to keep feedback fast.

Typical approach:

  • Use pre-commit (Python) or husky + lint-staged (Node).
  • Block commit when accessibility checks fail.
  • Keep checks deterministic and under ~30-60 seconds.

3) PR gate in CI

  • Re-run accessibility checks in CI for trust and consistency.
  • Fail PR checks on blocking accessibility regressions.
  • Publish actionable results and artifact links.

4) Scheduled depth scans

  • Run deeper scans on a schedule (nightly/weekly).
  • Use issue automation to create and label findings.
  • Trend metrics over time in your ACCESSIBILITY.md table.

Policy model to encourage adoption

  • Fast fail locally: contributors get immediate feedback before push.
  • Strict PR enforcement: no merge with blocking accessibility failures.
  • Transparent metrics: show pass rate, open defects, and remediation trend.
  • Waiver discipline: only time-bound waivers with explicit owner and expiry.

Suggested Definition of Done addition

No UI-impacting commit is accepted unless local/pre-commit accessibility checks pass and PR CI accessibility checks are green.

References