Most teams think about accessibility once a year, when someone forwards a compliance memo. The rest of the year, a11y is invisible — not because it doesn't matter, but because sighted engineers don't hit the barriers. This is a proposal to reframe: accessibility as engineering discipline, not compliance box-checking. Practiced daily, in small doses, with the same rigor as testing or security. Less dramatic; more effective.
The compliance framing fails
Compliance framing goes like this: get a VPAT, run an audit sprint before a release, remediate the issues that break the audit, submit paperwork, move on until next year. This model has three fatal flaws:
Audit fatigue. Big audits find hundreds of issues. Team gets overwhelmed. Half get fixed; other half get triaged into oblivion. Next audit surfaces same issues plus new ones.
Regression. Fixes made during audit sprint get regressed by unrelated work three months later. Nobody notices; screen reader users notice.
Actual users get an accessible product only briefly. Between audit and regression, users' experience is fine. The rest of the year: nope.
The engineering framing goes differently. A11y as part of every PR, checked continuously, owned by whoever wrote the code, integrated into normal review discipline. Not a project; a practice.
What changes with engineering framing
Concretely, here's what shifts:
A11y checks in CI. axe-core runs on every build. New a11y issues introduced by a PR block merge; existing baseline documented and reduced over time. See the /a11y-audit command for the shift-left version.
A11y in code review. Reviewer checks: are new interactive elements keyboard-accessible? Is contrast sufficient? Are form fields labeled? Same discipline as checking for security bugs or performance regressions.
A11y in design review. Design gets a11y review before it becomes engineering. Fixing color contrast in design is 10 minutes; fixing after implementation is hours.
Component library as accessibility contract. Reusable components (buttons, inputs, modals) are built accessibly once; consumers get accessibility for free. Rolling your own modal = rolling your own accessibility bugs.
Screen reader testing in the loop. Someone on the team uses NVDA or VoiceOver periodically. Even non-daily use catches issues automated audits miss.
What we learned from two years of this
We shifted to the engineering-discipline model about 20 months ago. Some observations:
1. Baseline matters more than perfection. Our codebase had ~400 automated a11y issues on day one. We didn't try to fix all of them; we established the baseline, blocked regressions, and cleaned up incidentally as code got touched. 20 months later: ~40 remaining. Steady reduction beats crisis sprints.
2. Component library was the highest-leverage fix. Once our button, input, modal, and dropdown components were accessible, most a11y issues stopped appearing in new code. One-time fix; permanent benefit. Design-system-level a11y > per-page a11y.
3. Automated audits catch about 40%. We measured. axe-core caught 40% of issues that manual audit surfaced. That 40% is the mechanical stuff (missing alt, contrast, unlabeled forms). The 60% needs humans: focus order, screen reader announcements, custom widget behavior, interaction patterns.
4. Keyboard-only testing catches surprisingly many issues. Once a month, someone on the team uses the product with keyboard only for an hour. Finds things automated audits miss and screen reader testing doesn't. Cheap and high signal.
5. Support ticket sentiment improved. Fewer tickets from users with disabilities complaining about specific pages. More tickets from those users using the product for advanced features. Signal shifted from “this page doesn't work” to “can this advanced flow work like X?” That's product feedback, not bug reports.
What Claude Code changed
Several pieces got materially cheaper:
Automated audits — /a11y-audit integrates axe-core + pa11y invocations; produces WCAG-referenced report; suggests specific fixes. Was 30 minutes of manual axe-core + interpretation; now 2 minutes.
Fix generation — Claude Code handling boilerplate ARIA additions, alt text drafting, label associations. Not perfect (still needs review) but 80% of trivial fixes ship faster.
Design-system component reviews — When we build or refactor a shared component, ask Claude Code to audit the a11y story. Catches issues that don't come up in normal review.
WAI-ARIA authoring practice validation — Custom widgets get validated against WAI-ARIA patterns. Combobox, listbox, dialog: standardized patterns exist; deviating creates a11y bugs. Claude knows the patterns; humans check the implementation.
Nothing revolutionary. But the compounding effect: a11y checking that used to take a full sprint every quarter is now background noise in normal development.
What doesn't change
Being honest about the limits:
Actual users testing with actual assistive tech is irreplaceable. Automated audits catch mechanical issues; users catch actual usability problems. Budget for user testing with assistive tech users; make it recurring not one-off.
WCAG isn't accessibility. Passing WCAG AA is table stakes; being genuinely usable by users with disabilities is more. Screen reader users appreciating your product is a stronger signal than passing axe-core.
Some things are hard. Data visualizations, complex interactive widgets, video content, drag-and-drop. These require specific expertise; automation only helps at the margins.
Design system doesn't cover custom. One-off pages, marketing sites, experimental features: still need attention. Design system contract is baseline; not ceiling.
What to do with this
If your a11y model is compliance-sprint: start shifting. axe-core in CI is one afternoon of setup. Baseline first; block regressions; reduce baseline incrementally.
If your design system is inconsistently accessible: fix the design system. Highest leverage change; one-time cost; permanent benefit.
If you never do keyboard-only or screen reader testing: pick a day. Even a monthly hour catches issues automated tools miss. Doesn't require expertise; just observation.
If you want depth: the accessibility discipline guide walks the full practice. This blog is the “why;” the guide is the “how.”