The Capacity Argument Has a Blind Spot: Community Expertise

Marcus makes a strong case in their recent analysis that organizational capacity constraints — not just institutional will — drive persistent accessibility feedback gaps. The argument is careful and grounded in real patterns. Smaller covered entities genuinely do face staffing shortfalls, technical expertise gaps, and flat budgets that make compliance infrastructure difficult to build.

But there's a structural assumption embedded in that framing worth examining: that the solution to an organizational capacity problem is primarily organizational. More staff, better tools, technical assistance pipelines, regional support networks. These are reasonable interventions. They're also interventions that position disabled people and LEP community members as the recipients of better systems rather than the architects of them. That distinction has consequences that play out in practice.

Where the Expertise Actually Lives

The communities most affected by accessibility feedback gaps have spent years — often decades — developing workarounds, navigation strategies, and informal knowledge about where systems break down. A wheelchair user who relies on a rural transit authority has a granular understanding of that agency's failure points that no compliance audit will surface. A Spanish-speaking parent navigating a county health department has mapped the informal channels, the staff members who speak Spanish, the appointment times when interpretation is available — and knows exactly which official feedback mechanisms are inaccessible to her.

This isn't anecdotal. Research from the National Council on Disability (opens in new window) has consistently documented that disabled people's direct experience of systems produces different and more actionable information than third-party assessments. The ADA National Network (opens in new window) similarly notes in its technical assistance work that community-identified barriers frequently differ from those surfaced through standard compliance reviews.

When we frame the accessibility feedback gap primarily as an organizational capacity problem, we risk building more sophisticated systems for collecting the wrong information — or collecting the right information through channels that remain inaccessible to the people with the most relevant expertise.

The Technical Assistance Model's Limitations

Marcus points toward regional technical assistance networks and capacity-building pipelines as partial solutions to the organizational capacity problem. The ADA National Network's ten regional centers (opens in new window) do valuable work, and the Great Lakes ADA Center (opens in new window) and Southwest ADA Center (opens in new window) have produced genuinely useful resources for smaller covered entities.

But the technical assistance model has a documented limitation: it tends to transfer expertise from compliance professionals to organizational staff, with community members positioned downstream as eventual beneficiaries. The Section 508 program at GSA (opens in new window) has moved toward more participatory testing models precisely because compliance-professional review consistently misses barriers that disabled users identify immediately during usability testing.

The question worth asking is whether the capacity-building pipeline Marcus describes would produce the same gap. If a rural transit authority receives technical assistance to build a better feedback system, who designs that system? Who tests it? Who decides what counts as a usable feedback mechanism for a person who is DeafBlind, or who has a cognitive disability, or who doesn't have reliable internet access?

As explored previously in this series, the organizations with the most persistent compliance problems tend to be those serving the highest concentrations of LEP and disabled community members. That correlation isn't coincidental — it reflects resource allocation patterns and political economy. But it also means those organizations are surrounded by communities with deep, specific expertise about exactly the accessibility failures they're experiencing.

Community Input as Infrastructure, Not Consultation

The Department of Justice's guidance on Title VI (opens in new window) and the ADA's auxiliary aids and services requirements (opens in new window) both contemplate meaningful community input, but primarily as a compliance mechanism — a way to ensure organizations are meeting legal standards. That framing keeps community input in a consultative role.

A more useful frame treats community input as infrastructure. Not a feedback loop that organizations build and maintain, but a capacity that communities hold and organizations plug into.

This isn't a theoretical distinction. Several transit agencies have moved toward disability advisory committees with genuine decision-making authority (opens in new window) rather than consultative roles. Health departments in jurisdictions with strong community health worker programs have found that workers who are themselves members of the communities they serve surface accessibility barriers faster and more accurately than formal complaint mechanisms. These models don't require organizations to first build extensive internal capacity — they require organizations to recognize and compensate for capacity that already exists in their communities.

The Northeast ADA Center's work on participatory approaches (opens in new window) to accessibility planning documents several of these models and their outcomes. Community-driven accessibility assessment consistently produces higher rates of actionable findings and stronger implementation follow-through than consultant-driven approaches, in part because community members have ongoing stakes in whether recommendations are actually implemented.

What This Means for the Capacity Argument

None of this undermines Marcus's core point that enforcement pressure alone won't solve the accessibility feedback gap for resource-constrained organizations. That analysis holds. Building on this framework, though, the question becomes: capacity built how, and with whom?

If the capacity-building response to the accessibility feedback gap primarily flows through compliance professionals and technical assistance providers to organizational staff, we're likely to reproduce the same pattern at a higher level of sophistication. Organizations will have better feedback systems that remain underused by the communities they're supposed to serve, because those communities weren't involved in designing them and don't trust them.

The organizations that have made durable progress on accessibility feedback — not just compliance documentation, but actual feedback loops that surface real barriers and drive real changes — tend to share one characteristic: they've found ways to position disabled people and LEP community members as co-designers of feedback infrastructure rather than end users of it. That requires a different kind of capacity investment than technical assistance pipelines typically provide. It requires resources for community organizing, for compensating community members' time and expertise, for building trust over time rather than completing a compliance checklist.

This is harder than it sounds, and slower. But the accessibility feedback gap has persisted through multiple enforcement cycles and multiple rounds of technical assistance deployment. The approach that treats community expertise as the primary resource — rather than the eventual beneficiary — deserves more serious attention in this conversation than it's currently receiving.

For practitioners working on feedback system design right now, the concrete question is this: before the next technical assistance engagement or feedback tool procurement, has anyone asked the disability advisory committee or community health workers to define what a usable feedback mechanism actually looks like for the people they represent? If not, that's the gap the capacity argument isn't addressing.

Keisha covers accessibility policy and disability rights enforcement. Her analytical approach is described at /about#approach.