Language Access Infrastructure Starts With the User, Not the System

Marcus makes a compelling case in his analysis of language access as operational infrastructure rather than a compliance checkbox. The procurement gap he identifies is real, and the critique of stale translated content is well-documented in practice. But there's a dimension that operational frameworks consistently underweight: the communities experiencing these failures aren't passive recipients waiting for better infrastructure. They're active participants whose knowledge, language patterns, and lived experience should be shaping what gets built.

This isn't a soft counterpoint about community engagement as a nice-to-have. It's an argument that infrastructure designed without community input tends to replicate the same exclusions it was meant to solve — just with better documentation.

Who Defines "Functional Equivalence"?

The Department of Justice's LEP guidance (opens in new window) uses the phrase "functional equivalence" as a standard for meaningful access. Marcus references this correctly. But functional equivalence is not a technical specification — it's a judgment call that requires knowing what function the content is supposed to serve for a specific community.

Consider a benefits enrollment page translated into Spanish. A linguistically accurate translation that uses formal Castilian Spanish may be functionally inaccessible to a Guatemalan Mam speaker whose Spanish is a second language. A translation calibrated for Mexican Spanish may miss the regional vocabulary patterns of a Puerto Rican community. The LEP.gov four-factor framework (opens in new window) asks organizations to consider the number and proportion of LEP persons served — but it doesn't ask who those persons are, what dialect they speak, or what their literacy level is in their primary language.

This is where infrastructure thinking, applied too narrowly, creates a new category of failure: technically compliant, operationally maintained, and still inaccessible to the actual humans it's supposed to serve.

The Dialect and Literacy Dimension

According to the Migration Policy Institute (opens in new window), a significant portion of limited English proficiency populations in the United States are speakers of indigenous languages from Latin America — Mixtec, Zapotec, Mam, and others — for whom Spanish is itself a second language. Standard Spanish translation workflows don't reach these communities at all. Neither do most procurement contracts, which typically specify target languages at a high level without accounting for regional or community variation.

Literacy adds another layer. The National Center for Education Statistics (opens in new window) has documented that literacy levels vary substantially within language communities, meaning that written translation — however accurate and current — may not be the appropriate access modality for all users. Audio content, plain language, and visual communication may be more effective for specific populations.

None of this is captured in a translation contract renewal cycle. It requires ongoing relationships with communities, not just ongoing maintenance of content.

What Community-Centered Infrastructure Actually Looks Like

This isn't an argument against the operational infrastructure Marcus describes — his framework for treating language access as a persistent system is the right direction. The question is what inputs that system should be running on.

Community-centered language access infrastructure has a few distinguishing characteristics:

Co-design over translation review. Rather than translating content and then asking community members to review it, organizations that do this well involve community members in defining what information is most critical, what format is most accessible, and what terminology resonates. The Pacific ADA Center (opens in new window) and similar regional technical assistance centers have documented approaches to community engagement in accessibility planning that apply directly here.

Trusted intermediary networks. Community health workers, legal aid navigators, and community-based organizations often serve as the actual access point for LEP individuals interacting with government services. Infrastructure that routes around these networks — building direct digital access without accounting for the role of intermediaries — may reach fewer people than a hybrid model that invests in both.

Feedback loops with teeth. Section 508 of the Rehabilitation Act (opens in new window) requires federal agencies to provide accessible information and communication technology, but feedback mechanisms for language access failures are rarely as structured as those for technical accessibility failures. Building in formal complaint pathways and response protocols — and publishing data on them — creates accountability that procurement cycles alone don't.

The WCAG Gap in Language Access

The Web Content Accessibility Guidelines (opens in new window) provide a technical framework for accessibility that has become the de facto standard for digital compliance. But WCAG's language-related success criteria — primarily 3.1, which addresses language identification — are structural rather than substantive. They tell browsers what language a page is in; they don't assess whether the translation is accurate, current, or appropriate for the target community.

This creates a gap that Marcus's infrastructure argument addresses partially but not completely. An organization can have excellent translation workflows, current content, and proper language tagging in their HTML — and still be producing content that doesn't serve the communities it's intended for. Technical infrastructure and community relevance are both necessary; neither is sufficient alone.

As I've outlined in my approach to balanced accessibility analysis, the most durable accessibility solutions tend to emerge when technical rigor and community knowledge are treated as complementary inputs rather than sequential steps.

Reframing the Infrastructure Question

Building on the operational framework Marcus articulates, the question for practitioners isn't just "do we have systems to keep translations current?" It's a set of harder questions: Current for whom? Accurate in whose dialect? Accessible at what literacy level? Delivered through what channels? Validated by which community members?

Organizations that treat these as implementation details to be resolved after the infrastructure is built tend to find that the infrastructure doesn't perform as expected. Organizations that treat community knowledge as a design input — not a feedback mechanism — tend to build systems that actually reach the people they're designed for.

The 25 million people with limited English proficiency in the United States aren't a monolithic constituency. They speak hundreds of languages, represent dozens of literacy levels, and interact with digital services through a wide range of contexts and intermediaries. Infrastructure that accounts for that complexity from the start is harder to build. It's also the only kind that works.