Building an Accessibility-First Culture

The plain-language idea

This lesson ties together three process-oriented ideas covered earlier in this track: integrating accessibility into code review, running audits and prioritizing what they surface, and publishing an accessibility statement. Each of those is a mechanism. This lesson is about what makes those mechanisms hold up over time instead of quietly decaying.

Here's the pattern, and it's a direct parallel to a well-known one in general engineering culture: a team runs an accessibility audit, fixes everything the audit found, and ships. Six months later, a meaningful chunk of the same issues are back. Not because anyone regressed on purpose — because nothing structural changed about how the team ships new code. The same pressures that let the issues in the first time are all still there afterward: a tight deadline that skips the a11y pass "just this once," a new engineer who's never seen the team's ARIA patterns and doesn't know they exist, a new third-party date-picker or dropdown library that nobody checked for keyboard support before pulling it in. A one-time fix-everything project addresses the symptoms that existed on the day of the audit. It does nothing about the process that keeps generating new ones.

Durable accessibility means treating it the same way a mature team treats correctness or performance: not as a project, but as an ongoing property enforced by the team's actual workflow.

See it in a real thing: what "structural" actually means

Three concrete pieces make the difference between "we did an accessibility push" and "this team ships accessible software by default":

Automated testing enforced in CI, not manually remembered. A contrast check, an axe-core scan, a keyboard-navigation smoke test — run automatically on every PR, blocking merge on failure — catches regressions the moment they're introduced, before they ship, without depending on any individual remembering to check. A checklist item in a wiki page that nobody's required to consult catches nothing.

# .github/workflows/a11y.yml (illustrative)
- name: Accessibility scan
  run: pnpm exec playwright test --grep @a11y
  # Fails the build on any new axe-core violation — no PR merges around it

Accessibility as a normal code review item, not a specialist's job. If checking for a missing aria-label, an unmanaged focus trap, or a color-only status indicator only happens when a designated accessibility specialist happens to review a PR, coverage is a function of who's available that week, not of the code's actual quality. Folding it into the same review checklist every reviewer already uses — alongside "does this handle the error case," "is this covered by a test" — makes it everyone's job by default, which is the only way it scales past whatever one specialist can personally review.

Accessibility bugs triaged like functional bugs, not shelved in a separate backlog. A keyboard trap that makes a modal impossible to close without a mouse is not a lesser bug than a modal that crashes the page — for the user who hits it, it's just as blocking. Teams that maintain a separate, permanently-low-priority "accessibility backlog" are implicitly telling themselves these bugs matter less, and a backlog that's implicitly deprioritized is a backlog that never actually gets worked.

What people usually miss

Watch out

• An audit-and-fix project is valuable, but it's not the finish line — it's the input to deciding what structural gaps let those issues in. Treating the audit's fix list as "done" without asking why those issues existed in the first place guarantees a similar list next year.
• "We'll remember to check" is not a process — it's a hope. Every structural piece here exists specifically because individual memory and goodwill don't survive deadline pressure, team turnover, or a new dependency nobody thought to vet.
• Making accessibility "everyone's job" doesn't mean no one owns it. The teams that do this well still often have someone driving standards and reviewing hard cases — the shift is that baseline checks don't bottleneck on that person being in the room.
• A separate accessibility backlog isn't neutral — it's a demotion. Even with the best intentions, routing a11y bugs into their own track signals, structurally, that they're a different (lesser) category of bug than a functional one, and teams behave accordingly over time.

Why this matters in interviews

"How would you make sure accessibility fixes actually stick after a redesign?" is a real, senior-leaning question, and it filters for candidates who reach for process — CI enforcement, code review norms, bug triage parity — rather than a one-time audit repeated on a schedule, which is the same fix applied over and over without addressing why it keeps being needed.