Accessibility is a reliability concern

A user opens your product with a screen reader running. The interface will fail them some percentage of the time. The question is not whether, but how often, on which tasks, and what happens when it fails.

If that sentence sounds familiar, it is because the Reliability Layer manifesto opens the same way about production AI. The repetition is the point. I have spent twenty years on the accessibility version of this question (HIPAA-regulated healthcare systems, WCAG AAA client work, an accessible React Aria component library, screen reader testing across NVDA, VoiceOver, and JAWS) and the last several on the AI version. They are the same engineering posture asked of two different substrates: does the system actually work for the person in front of it, or does it work in the benchmark?

Nobody, as far as I can tell, is treating them as one discipline. A research sweep I ran in July 2026 looking for practitioners who unite generative-AI reliability work with accessibility found none. One sweep is not proof of nonexistence. It is enough to say the connection is underarticulated relative to how load-bearing it is. This piece is the articulation.

The same failure, twice

The manifesto’s central failure class: a system performs within its trained distribution, the observability dashboards are green, and the deployment still fails a class of user because nothing at runtime checks the output against what this input actually required. Benchmark accuracy is a statement about a distribution. The user in front of the system is a sample of one.

Accessibility engineering has been living with exactly this failure class for decades, under different names. A page passes every automated conformance check. The dashboards, such as they are, show green: no missing alt attributes, no contrast violations the tooling can compute, ARIA syntax valid. A screen reader user still cannot complete checkout, because the dynamic error message renders visually without ever reaching the accessibility tree, or the custom widget traps focus, or the reading order makes the form unintelligible in sequence. Every check passed. The task failed.

Both fields converged, independently, on the same hard-won findings:

Automated checks are necessary and nowhere near sufficient. In AI evaluation, the benchmark qualifies the model; it does not qualify the deployment. In accessibility, automated tooling covers the mechanically decidable subset of WCAG success criteria and cannot decide most of the judgment-bearing ones: whether alt text is accurate rather than merely present, whether the reading order makes sense, whether the label describes the control’s purpose. Passing the automated tier tells you the system has not failed in the ways machines can notice. That is a floor, and both fields have watched teams mistake it for a ceiling.

Verification must terminate at the artifact. In my AI work, the rule is that a claim about a system is verified against the countable files, never against a spec or summary describing them. Accessibility has the same rule with a different artifact: the terminus is a person using assistive technology completing a real task. Not the conformance report, not the linter output, not the component library’s documentation asserting the widget is accessible. Those are downstream surfaces citing the artifact. When verification stops at them, it did not happen.

Abstention is a first-class outcome. A fact-checker that always commits is miscalibrated, which is why my verification work treats “unverifiable” as a verdict and measures whether the abstentions were correct. Mature accessibility tooling made the same move: the better automated checkers return a needs-human-review category alongside pass and fail, an explicit refusal to commit on criteria the tool cannot decide. An accessibility scanner that reports only pass or fail is overcommitting in precisely the way an overconfident model does, and it produces the same downstream harm: false assurance, priced in later.

Everything degrades silently without gates. An accessible interface decays the same way a calibrated model does: one dependency upgrade, one redesigned component, one refactor that nobody exercised with a keyboard. The regression ships because nothing asked the gate to prove it was still working. Accessibility regressions and reliability regressions share a signature: invisible to the team, obvious to the affected user, discovered by the worst available channel.

Four concerns, same taxonomy

The manifesto frames the Reliability Layer as four runtime concerns: verification, calibration, adversarial robustness, recovery. Accessibility does not need a fifth concern added for it. It is territory the existing four already cover, once you notice that an interface is a system output and a user session is runtime.

Verification. Does evidence support the claim that this flow works? For an interface, the evidence hierarchy runs from automated conformance checks (cheapest, weakest) through manual expert review to assistive-technology task completion (costliest, terminal). A deployment that claims accessibility on automated evidence alone is running a verification gate with a known, large false-negative blind spot, and should say so.

Calibration. Confidence should track reality, per finding. An automated contrast check deserves high confidence; a heuristic judgment that a label is “probably descriptive enough” does not, and the difference should be legible in the report. Tooling that presents both finding types with identical certainty is miscalibrated, whatever its accuracy. This is the same requirement I put on verification verdicts, applied to audit findings.

Adversarial robustness. No adversary constructs accessibility failures, so the mapping here is loosest, and it is still useful. The structural question is identical: what happens to system behavior under interaction conditions the happy path did not anticipate? Keyboard-only navigation, 400% zoom, forced-colors mode, a screen reader traversing the DOM in an order no sighted developer ever sees. These are the interface’s out-of-distribution inputs. A team that only tests the mouse-and-default-viewport path has evaluated in distribution and deployed out of it.

Recovery. When the primary interaction fails, where does the user land? Progressive enhancement is graceful degradation under a different name: the form still submits without JavaScript, the custom widget falls back to the native control, the error is announced rather than merely painted. An interface with no recovery path fails the way an AI system without escalation logic fails: silently, terminally, at the exact moment the stakes arrived.

The intersection runs both directions

Treating the two fields as one discipline pays off in two distinct directions, and most teams need both.

Making AI systems accessible. AI products are interfaces. The verification pipeline I co-founded, Veridi (invite-only beta; a 7-agent pipeline on FastAPI and the Anthropic SDK), produces verdicts a person has to read, and some of those people will be using assistive technology, high zoom, or reduced motion. Small example from that codebase: verification runs take long enough to warrant a waiting animation, and the animation honors prefers-reduced-motion with a plain text status line instead. That is engineering work, and I state it as exactly that: unaudited engineering work, a conformance claim I have not earned yet. The general point stands independent of my example. Chat streams, confidence displays, citation trees, agent-progress indicators: the AI industry is currently minting new interface patterns at speed, mostly without asking how they read in an accessibility tree. Every one of them is a reliability surface, because a verdict a user cannot perceive is operationally identical to a verdict never delivered.

Using AI agents to evaluate accessibility. The judgment-bearing WCAG criteria that automated tooling abstains on (is this alt text accurate? does this link text describe its purpose?) are language-understanding problems, which is why LLM-based evaluation is a live research direction. A 2024 study in Universal Access in the Information Society (DOI 10.1007/s10209-024-01108-z) had LLM-based scripts correctly determine the expected outcome on 34 of 39 WCAG-ACT test cases (87.18%) across three success criteria that normally require manual evaluation. The six automated evaluators they benchmarked against scored 0% at identifying the deliberately broken variants of those same cases. I have working instances on my side of the fence: among the more than 80 Claude Code skills I have authored (with test-contracts; sourcing on the colophon), agent-driven accessibility auditing runs inside real production gates for my commercial WordPress work.

The limits deserve equal billing, because this is exactly where an uncalibrated tool does harm. An agent can surface candidate failures, draft findings with cited criteria, and cover far more surface per hour than a human auditor. What it cannot do is close the loop. Conformance judgment is a human call. Whether a flow is usable by an actual person with an actual screen reader is decided by that person completing the task, and by nothing upstream of it. An LLM auditor is a verification stage whose output needs its own calibration data: findings with confidence attached, an explicit needs-human-review verdict, and a measured false-positive rate. In other words, using AI to test accessibility is itself a Reliability Layer problem, and it should be built like one.

What I have built here

The claim that these are one posture is easier to make if the same hands have done both, so, the record. Twenty years of accessibility-as-architecture: seven of them on HIPAA-regulated systems at the National Marrow Donor Program, WCAG AAA enhancement work at Nerdery, a React Aria component library built to WCAG AA and AAA at ButcherBox, screen reader testing as routine practice rather than launch ritual. The current instantiations carry both threads at once. NetterTech Events, my commercial WordPress suite, is WCAG 2.2 AA across its user surfaces and gated by 10,000+ automated tests, with the free core published on WordPress.org: accessibility and reliability discipline in one shipped artifact. Veridi carries the inverse: a reliability system (calibrated confidence, selective Brier 0.0253 across the 89 committed verdicts in a 100-claim calibration set, abstention correct on all 11 of the claims it declined) whose interface work is starting to be held to the accessibility standard I hold client work to. Starting: the conformance audit is unfinished business, and it is listed as such.

What I am uncertain about

Whether the framing earns adoption. “Accessibility is a reliability concern” is true in the structural sense argued here; whether reliability engineers pick up accessibility work, or accessibility specialists pick up calibration vocabulary, is a sociological question this essay cannot settle. The two communities publish in different venues and mostly do not cite each other.

Where the analogy strains. Adversarial robustness maps loosely, as noted. And accessibility carries a legal and ethical weight (it is about people’s access to services, employment, civic participation) that “reliability” as a category does not fully express. The taxonomy covers the engineering; it does not claim to cover the obligation.

How far LLM evaluation gets. The cited detection results are promising and narrow: a few success criteria, controlled test cases. Whether agent-driven auditing generalizes across the judgment-bearing criteria at trustworthy calibration is open, and I intend to measure rather than predict.

The diagnostic, in the manifesto’s spirit: when your system produced its last output, could the person it was for actually receive it? If you know the answer only for the benchmark user, the gap is the work.