The accessibility program

Healthcare platforms carry a legal duty of access: ADA Title III, Section 504 of the Rehabilitation Act, and — increasingly decisive — enterprise procurement, where a deal stalls without a credible VPAT. As the point person for accessibility at Qualifacts, I work across compliance, sales, and legal on exactly those questions, and I built this program so the answers rest on evidence instead of assertion.

Two products, audited patient-first: OnCall’s web app (React), native iOS (Swift), and native Android (Kotlin), plus the InSync patient portal (ASP.NET MVC). Explore the real counts:

Scoping was itself a deliberate decision: patient-facing surfaces first, because that is where the legal exposure and the human stakes concentrate. Provider-only findings (92 on OnCall) were preserved in the repo but excluded from reports rather than diluting them.

Every surface got two passes. First, automated static code analysis — an agent I directed swept each codebase for statically detectable failures: missing accessible names, ARIA misuse, unlabelled inputs, touch targets under platform minimums (44×44pt iOS, 48×48dp Android), Razor helpers emitting unlabeled controls. Then manual runtime testing on physical devices — VoiceOver and Switch Control on iPhone, TalkBack and Switch Access on Pixel, keyboard-only and screen-reader passes on web — covering what static analysis cannot see: focus order, announcement accuracy, modal trapping, dynamic content.

Each audit lives as a version-controlled repo where findings/combined.json is the single source of truth, and everything downstream is generated by scripts: an interactive dashboard, a formal VPAT, a leadership summary for executives, WCAG failure reports, and a Jira-ready export. Re-run the pipeline, every document updates. An MCP pipeline then wrote the findings into Jira as structured, engineer-assigned stories — two epics on OnCall (web + iOS), verified shipping, with early fixes already merged.

audit-dashboard.html — generated from combined.json, every re-run

vpat.html — the formal conformance report procurement asks for

The pattern that emerged from the data drives the remediation strategy: 4.1.2 Name/Role/ Value and 1.3.1 Info & Relationships dominate every surface — component-level naming and semantics failures. That is precisely what the design system fixes by construction, which is why its accessible primitives (audited, axe-gated in CI) are the long-term remediation path, not screen-by-screen patching.

There is no accessibility team behind this — there is a system. The audit skills (a11y-audit, a11y-runtime) make code review repeatable across React, Swift, Kotlin, and Razor. The design system makes new UI accessible by construction, with axe blocking merges in CI. The Figma contrast plugin clears 100+ customer brand checks a year before they ever reach support. The MCP pipeline turns findings into assigned engineering work without a project manager in the loop. Each piece replaces a role the program was never going to be given.

The other half is the human part: I’m the accessibility point person across the org — the person compliance calls about a 504 question, sales calls when procurement asks for a VPAT, and legal calls when a customer letter arrives. The program’s documents are built to survive those conversations, because they rest on 2,027 findings with file-and-line evidence, not on a checkbox.

Accessibility as an owned program, not a task: legal/compliance fluency (ADA, 504, VPAT), engineering reach across four stacks including native mobile, AI leverage with human verification, and the systems judgment to connect audit findings back to design-system architecture. Honest flag, kept on purpose: remediation is in its early innings — 24 OnCall fixes shipped at audit close, with the epics live and assigned.