The Floor Isn't Fixed: Community Input as Compliance Infrastructure

Jamie's analysis of who defines operational capacity exposes a real accountability gap. But the deeper problem may be structural: accessibility compliance frameworks still treat community input as feedback rather than foundational data.

In their recent analysis, Jamie correctly identifies that covered entities shouldn't be the primary authors of their own capacity assessments. The transit agency that claims multilingual complaint intake is beyond its operational reach while maintaining sophisticated fare optimization systems isn't describing a resource constraint — it's describing a priority structure. That distinction matters enormously for enforcement.

But there's a prior question the piece doesn't fully resolve: why do compliance frameworks default to covered entity self-reporting in the first place? The answer isn't incidental. It reflects a foundational design choice in how ADA enforcement architecture was built — one that has significant consequences for which failures get characterized as structural versus strategic.

How Institutional Self-Reporting Shapes ADA Enforcement

The ADA's enforcement model, as implemented through DOJ complaint processing (opens in new window) and agency technical assistance, is primarily reactive. A covered entity fails to provide access. An individual files a complaint. The entity responds with documentation of its processes and constraints. Investigators evaluate that documentation against legal standards.

This architecture places enormous weight on institutional self-description. Covered entities document their own capacity. They characterize their own resource constraints. They define what constitutes a good-faith compliance effort. The ADA National Network's technical assistance model (opens in new window) — valuable as it is — largely operates within this same paradigm, helping organizations understand and document their compliance efforts rather than building external accountability mechanisms.

The result is that community knowledge about accessibility failures exists largely outside the formal compliance record. Disabled people who navigate inaccessible systems daily accumulate detailed, granular knowledge about where systems break down, which barriers are consistent versus intermittent, and which organizational responses are genuine versus performative. That knowledge rarely enters compliance assessments in any systematic way.

This isn't a new observation. Disability rights scholars have documented (opens in new window) for decades that ADA enforcement underperforms relative to the statute's scope, and that the complaint-driven model systematically undercounts barriers that affect people who face the highest access burdens — people with multiple disabilities, people in rural areas, people whose primary language isn't English. The capacity argument Jamie examines is partly a symptom of this deeper architectural problem.

Community Input as Infrastructure, Not Feedback

The framing that matters here is the distinction between community input as feedback and community input as compliance infrastructure. Most covered entities, when they collect accessibility input at all, treat it as feedback — something to be reviewed, prioritized, and acted upon according to internal capacity and institutional priorities. That framing is precisely what allows the capacity argument to function as an accountability shield.

If community input is just feedback, then an organization that lacks the infrastructure to process it has a capacity problem. If community input is compliance infrastructure — meaning that systematic failure to collect, process, and act on it constitutes a compliance failure in itself — then the calculus changes fundamentally.

As explored previously, covered entities frequently invest in operational infrastructure that serves their primary institutional interests while characterizing accessibility compliance as a resource constraint. The question is whether accessibility feedback systems should be treated as optional infrastructure or as a core operational requirement on par with financial reporting or safety compliance systems.

Section 508 of the Rehabilitation Act offers a partial model here. Section508.gov's guidance on feedback mechanisms (opens in new window) treats accessibility reporting as an institutional accountability function, not just a customer service channel. Federal agencies are expected to maintain systematic processes for identifying and addressing accessibility barriers — processes that generate auditable records. That model doesn't fully resolve the self-reporting problem, but it shifts the frame from "do you have capacity to receive feedback" to "do you have systems that generate compliance-relevant data."

What Community-Defined Accessibility Metrics Would Actually Require

Jamie's piece raises the right question about who defines the floor. My argument, building on our editorial approach to community-centered analysis, is that answering that question requires more than better oversight of covered entity self-assessments. It requires building community input into the measurement infrastructure itself.

What would that look like in practice? The Great Lakes ADA Center's work on participatory compliance (opens in new window) offers some direction. Genuine community-defined metrics require disabled people to be involved not just in reporting barriers but in defining what adequate access looks like, what response timelines are acceptable, and what constitutes a good-faith remediation effort. That's a fundamentally different role than complaint filer.

The Web Content Accessibility Guidelines development process (opens in new window) — imperfect as it is — demonstrates that technical standards can incorporate community input systematically rather than treating it as anecdotal. WCAG's success criteria emerged from a process that included disabled users in defining what functional access actually requires, not just what's technically feasible for developers to implement. That model doesn't translate directly to ADA compliance assessment, but the underlying principle does: standards defined without the people they're meant to serve will systematically underweight their actual needs.

For covered entities, this would mean accessibility feedback systems designed with disabled community members, collecting data in formats that reflect actual access barriers rather than institutional reporting convenience, and generating records that external reviewers — not just internal compliance staff — can evaluate. The DOJ's technical assistance resources (opens in new window) gesture toward this kind of accountability, but implementation guidance rarely specifies community involvement in the design of feedback systems themselves.

The Accountability Gap Is a Design Gap

The capacity argument works as an accountability shield because compliance architecture was designed around institutional reporting rather than community-generated data. Covered entities can credibly claim capacity constraints partly because the system doesn't require them to build community input infrastructure in the first place.

Building on this framework, the enforcement question isn't just whether covered entities are accurately describing their capacity constraints. It's whether the compliance system itself has the right data sources to evaluate those claims. Right now, it largely doesn't — and that gap benefits the entities making the claims.

Community input isn't a supplement to compliance infrastructure. For covered entities that serve disabled people, it is compliance infrastructure. The floor isn't fixed until the people living below it have a systematic role in defining where it sits.

Keisha covers accessibility policy and enforcement for this publication. Her analysis emphasizes community-centered frameworks and the structural dimensions of disability rights implementation. See our editorial approach for more on how we cover these issues.