Accessibility is an engineering practice, not an audit

Accessibility usually fails not because a team doesn't care, but because of when they decide to. Build the whole product, book an audit near the end, then triage a long list of findings against a ship date that's already slipping. By then the problems are baked into components used in fifty places. The people who wrote them have moved on. And accessibility turns into a tax paid under duress instead of a property of the work. I've come around to thinking the fix has to be structural. Stop treating it as a phase. Start treating it as engineering, something enforced on every change, by machines, all the time.

An audit is a snapshot; a gate is a ratchet

An audit tells you how the product looked on one day. The next pull request makes that picture old. A CI gate works differently: once a check is in place, the build refuses to go backward. A color pairing that misses contrast, a div pretending to be a button, or an image without useful alternative text should fail close to the code that caused it. On this site, Lighthouse and browser-based axe checks run against the published route inventory in English and Spanish, in light and dark. Dynamic controls have their own interaction tests. That does not replace human judgment. It keeps preventable failures out of the way so people can spend their attention on what only people can judge.

Where the checks live

No single tool catches everything, so I layer them. Each one runs on its own, and each one blocks a merge when it fails:

• axe inside the unit tests. Components get checked against accessibility rules at the smallest unit, so a violation shows up next to the code that caused it, not three integrations later.
• axe inside Playwright. The same rules run against fully rendered pages in a real browser, on every route in both languages and both themes, where dynamic state, focus order, and content that only exists after you interact are actually there to be checked.
• Lighthouse. A budget on the overall accessibility score that fails the pipeline if it slips below a perfect 1.0, catching whole-page problems the component tests can't see.

What these tools have in common is honesty about their own limits. Automated checks reliably catch a real share of accessibility problems, like contrast, missing names, broken roles, and malformed structure, but they can't tell you whether your alt text actually means anything, or whether someone using only a keyboard can finish the task. That's the whole reason I want machines handling the machine-checkable failures. It frees up the manual and assistive-technology testing for the judgment calls no linter will ever make.

Two different bars, on purpose

Be precise about which standard you're holding yourself to, because the honest answer changes with the stakes. WCAG, the Web Content Accessibility Guidelines, now version 2.2, which the W3C published as a Recommendation in 2023, defines three conformance levels: A, AA, and AAA. AA is a widely used baseline for public-sector digital services, although applicable requirements depend on the service and jurisdiction. AAA is the strictest level, and the guidelines themselves note it is not reachable for all content. That makes selected AAA criteria useful stretch goals for a small surface with a clearly defined scope.

For public services, I treat accessibility as an ongoing engineering practice: define a clear baseline, include automated checks in delivery, test important journeys manually, and make language access part of the same quality system. Metrics from any one tool are signals, not a broad conformance claim.

This portfolio is a smaller surface where I can test stricter choices. I target WCAG 2.2 AA and deliberately add selected AAA-level checks, including 7:1 text contrast. I have not completed the manual and assistive-technology review needed for a broader conformance claim, so I do not call the site AAA. The automated gates remain useful evidence of practice, and known gaps stay visible until they are addressed.

Why the gate changes the culture

The deepest reason I prefer gates to audits has nothing to do with tooling. It's what each one teaches a team. An end-of-project audit teaches engineers that accessibility is somebody else's job, checked later, by someone with a clipboard. A gate on every pull request teaches the opposite. Accessibility is your job, right now, the same as making the tests pass. When the feedback lands in minutes instead of months, people learn the rules by writing inside them, and the next component starts out accessible because that's just how the team builds. Accessibility stops being something you remediate and becomes something you have.

An audit asks, at the end, whether you got there. A practice makes sure you never left. For software that public institutions and the people who depend on them actually use, that difference isn't pedantry; it's the whole thing.