Language Access Infrastructure Starts With Community, Not Code

Marcus makes a compelling case for operational infrastructure in language access. But the deeper failure isn't procurement or maintenance cycles — it's that affected communities are rarely at the table when these systems are designed. In their analysis of language access as infrastructure, the focus lands squarely on organizational capacity: translation contracts, content drift, the four-factor LEP.gov framework. That framing is accurate as far as it goes. What it doesn't fully account for is why organizations keep building the wrong infrastructure even when they have the budget and the intent to do it right.

The answer, consistently, is that they're designing systems for communities they've never actually consulted.

Translation Is Not the Same as Communication

There's a persistent assumption embedded in most language access programs: that translating content into another language is equivalent to making it accessible to speakers of that language. Linguists and community health researchers have documented this gap for decades. Translation handles vocabulary. It doesn't handle literacy levels, dialect variation, cultural context, or the specific ways a community talks about a given topic — healthcare, legal rights, government benefits.

The National Council on Interpreting in Health Care (opens in new window) has published standards distinguishing translation from culturally competent communication since the early 2000s. Their work, and subsequent research in health literacy, consistently shows that professionally translated materials can still fail communities if the source content was written at too high a reading level, used institutional framing that doesn't map to how communities understand their own situations, or simply wasn't tested with actual users before deployment.

Plain language requirements under federal law (opens in new window) address part of this — the Plain Writing Act of 2010 requires federal agencies to use clear communication in documents directed at the public. But plain language in English and plain language in translation are different problems. An 8th-grade reading level in English doesn't automatically produce equivalent comprehension when translated into Spanish, Hmong, or Arabic without community review.

Who Gets Consulted, and When

The LEP.gov four-factor analysis (opens in new window) that Marcus references is a useful diagnostic tool. But it's worth examining what the four factors actually measure: population size, contact frequency, service importance, and organizational resources. None of those factors require organizations to ask LEP communities what they actually need, how they prefer to receive information, or whether existing materials are working.

This is a structural gap in the compliance framework itself. The Department of Justice's guidance on meaningful access (opens in new window) establishes that language services must be accurate, timely, and free — but the standard for "meaningful" is largely determined by the providing organization, not by the people being served.

Community-based organizations working directly with immigrant and refugee populations have been pointing this out for years. Groups like the National Immigration Law Center (opens in new window) have documented cases where government agencies produced technically compliant language access materials that communities found confusing, culturally inappropriate, or simply didn't trust — often because those communities had no role in developing them.

Trust is not a compliance metric, but it's operationally decisive. A translated benefits portal that a community doesn't trust won't be used, regardless of how current the content is.

The Participation Infrastructure Problem

As explored previously in this analysis of language access infrastructure, most organizations lack the maintenance systems to keep translated content current. That's real. But there's a prior problem: most organizations also lack any systematic process for involving LEP communities in content design, testing, or feedback.

This isn't unique to language access. The Web Content Accessibility Guidelines (WCAG) (opens in new window) framework, which governs digital accessibility broadly, has faced similar criticism from disability communities who argue that technical compliance doesn't equal usable access when the people writing the standards aren't centering the experiences of disabled users. The W3C's own Accessibility Guidelines Working Group (opens in new window) has made meaningful efforts to incorporate community input, but advocates have consistently noted that participation barriers — time, technical knowledge, language — limit who can actually engage with the standards process.

The parallel for language access is direct. Organizations can build technically sophisticated multilingual infrastructure and still produce systems that fail communities, because the communities weren't consulted on what "working" actually means for them.

At CORS Accessibility, our approach to community-centered analysis treats this as a foundational question: whose definition of access are we using? That question has to precede the operational and procurement questions, not follow them.

What Community-Centered Language Access Actually Requires

This isn't an argument against the infrastructure framing — it's an argument for expanding it. Genuine language access infrastructure includes:

Community advisory processes built into content development, not bolted on afterward. Several state health departments have developed formal community review panels for multilingual materials, particularly in public health contexts where communication failures have documented consequences. These aren't token consultations — they're structured feedback loops with compensated community reviewers who have standing to require changes.

Dialect and register awareness that goes beyond selecting a target language. Spanish-language materials developed for a predominantly Mexican-American community may not serve recent Central American immigrants with different vocabulary, cultural references, and trust relationships with institutions. Section 508 of the Rehabilitation Act (opens in new window) and related federal accessibility requirements don't address this — it requires organizational commitment beyond compliance.

Feedback mechanisms in target languages that actually reach the communities being served. Most organizational feedback processes — surveys, comment forms, help desk systems — are English-only by default. If you can't hear from LEP users about what's failing, you can't fix it.

Community-informed plain language standards that account for the actual literacy levels, vocabulary, and communication norms of specific communities. This requires ongoing relationships with community organizations, not one-time translation contracts.

The Northeast ADA Center (opens in new window) and peer regional ADA centers have developed resources connecting disability access and language access as overlapping civil rights obligations — a framing that recognizes both require sustained community engagement, not just technical compliance.

The Accountability Gap

Building on this infrastructure framework, the question of who holds organizations accountable for community-centered language access is genuinely difficult. Title VI enforcement through the DOJ and OCR provides a legal backstop, but complaint-driven enforcement is reactive and slow. Communities experiencing language access failures are often the least positioned to navigate federal complaint processes.

The organizations doing this well — and some are — tend to have built direct accountability relationships with community organizations that have enough standing to push back when materials aren't working. That's not a compliance mechanism. It's a governance choice. And it requires treating language access not as a technical problem to be solved once, but as an ongoing relationship with the communities an organization serves.

The practical implication: if your organization's language access program has no formal mechanism for LEP communities to identify failures and require a response, the program is incomplete — regardless of how well-maintained the translations are. That's the gap worth closing first.

The infrastructure matters. So does the question of who it's built with.