From Twice a Year to Every Month: Making Accessibility a Release Gate

When I joined Triomics, accessibility was reviewed when a report was due — roughly twice a year. That cadence has a predictable failure mode: by the time anyone looks, six months of features have shipped, the issues are baked into components other screens depend on, and every fix competes with roadmap work. A review that only happens twice a year isn't a practice. It's a compliance exercise nobody thinks about until it's due.

So I proposed two changes, and we made both stick:

1. A mandatory accessibility checklist before any new feature ships to production.
2. A monthly accessibility review across every product shipped that month, replacing the twice-yearly report.

The first moves the check to the point where fixes are cheapest. The second makes sure nothing waits half a year to be looked at.

What an audit actually runs

The automated half is Playwright walking every page and every form, with axe-core scanning each view against WCAG 2.0, 2.1, and 2.2 A/AA rules plus best practices. Findings are grouped by WCAG guideline and by impact — critical, serious, moderate, minor — and roll up into VPAT-style conformance reports.

But axe on its own leaves big gaps, so the suite carries around 25 custom checks for what axe doesn't cover: keyboard navigation and keyboard traps, focus order, focus not obscured (2.4.11), on-focus and on-input behavior, text resize and text spacing, non-text contrast, use of color, content on hover or focus, reading order, language of parts, link purpose, multiple ways, pointer cancellation, dragging movements, accessible authentication (3.3.8), and status messages.

Forms and sign-in get their own dedicated audit alongside the all-pages pass. That's where an accessibility blocker doesn't just inconvenience someone — it stops them outright.

Where automated scans stop

This is the part that matters most, and the part a passing scan hides:

• axe-core automates only one rule specific to WCAG 2.2 — target size. The rest of 2.2's new criteria need custom checks or a person.
• A scan confirms presence, not meaning. It can tell you alt text exists, not that it's useful; that a label is present, not that it makes sense; that focus is visible, not that the order is logical.
• Some heuristics are low-confidence. Every one of those findings needs a human call before it becomes a ticket, or the backlog fills with noise and people stop trusting it.
• Some criteria are manual on purpose. Error prevention (3.3.4) and redundant entry (3.3.7) are tested by hand, because automating them would change shared QA data other people depend on.
• Media, timing, and gesture criteria are checked manually too.

What manual and exploratory testing add

The automated suite tells you what's broken against a rule. The manual pass answers a different question: can someone actually complete this? That means keyboard-only passes through critical journeys end to end, the way a keyboard user really moves through the product; exploratory sessions on new features; and a manual checklist for everything a rule engine can't judge — meaning, context, and whether the experience holds together.

The lesson

The tooling was never the hard part. Moving the check ahead of production, and making the review a monthly habit instead of a report deadline, is what changed the outcome. Automation makes that habit cheap enough to sustain; it doesn't replace the judgment.