ES · EN

24 de septiembre de 2026

Cumplimiento ADA multilingüe: evita sanciones del DOJ

Reviewer testing bilingual website accessibility

Cualquier idioma que tu organización publique en la web tiene que ser tan accesible como la versión en inglés. Esa es la vara práctica que fija el Departamento de Justicia, y WCAG 2.1 Nivel AA es el criterio técnico que la respalda. Si atiendes a clientes hispanohablantes, lo primero que debes hacer es auditar el etiquetado de idioma y arreglar tus páginas de mayor tráfico y orientadas a transacciones antes que cualquier otra cosa.

En resumen:

  • Asegúrate de que todas las páginas multilingües tengan etiquetas de idioma detectables por el sistema para que la tecnología de asistencia pronuncie correctamente, sobre todo en el contenido en español.
  • Da prioridad a arreglar primero las páginas transaccionales como formularios, agendamiento de citas y portales de facturación, ya que son las que más quejas suelen generar y las que causan daño real.
  • Prueba las páginas traducidas con un lector de pantalla configurado en el idioma correspondiente y verifica que todos los encabezados, etiquetas y mensajes de error sean consistentes en estructura y en lenguaje.
  • Confirma que todo el contenido, incluyendo herramientas de terceros y widgets integrados, admita etiquetado de idioma y accesibilidad correctos antes de publicar.
  • Mantén el cumplimiento al día asignando a alguien la responsabilidad de verificar las etiquetas de idioma del contenido nuevo, actualizar la documentación de accesibilidad y hacer auditorías regulares en todos los idiomas.

Índice

Qué leyes de EE. UU. rigen el cumplimiento ADA multilingüe

La ADA divide las obligaciones según quién eres. El Título II cubre a las entidades de gobierno estatal y local. El Título III cubre a los negocios privados abiertos al público, incluyendo despachos de abogados, consultorios dentales y clínicas médicas. Ambos títulos alcanzan el contenido digital, y ambos ahora apuntan al mismo objetivo técnico.

La regla de 2024 del DOJ adoptó formalmente WCAG 2.1 Nivel AA como el estándar para el contenido web y las apps móviles operadas por gobiernos estatales y locales. Esa es una regla específica del Título II, pero se ha convertido en el punto de referencia de facto que jueces y abogados de demandantes citan cuando evalúan también sitios del Título III, ya que no existe un estándar técnico aparte para negocios privados. Las fechas de cumplimiento para entidades públicas están escalonadas según el tamaño de la población y los recursos, algo que la sección de excepciones más abajo cubre en detalle.

Los negocios del Título III operan bajo un estándar más amplio y más antiguo: la comunicación efectiva. Esto significa que cualquier información o servicio que ofrezcas en inglés, por lo general debes ofrecerlo con acceso equivalente en los otros idiomas que publiques. La guía del DOJ sobre comunicación efectiva es clara en que, una vez que eliges comunicarte en un idioma, la vara de accesibilidad para ese contenido no baja solo porque no está en inglés. Un formulario de citas en español que un lector de pantalla no puede interpretar no es comunicación equivalente, aunque la versión en inglés funcione a la perfección.

La regla final del DOJ también contempla cinco excepciones muy acotadas de la conformidad total:

Ninguna de estas excepciones cubre tus páginas activas y de cara al público en español o en inglés. Si tu organización solo prioriza una ronda de remediación, gástala en las páginas transaccionales: agendamiento de citas, formularios de admisión, portales de facturación y todo lo que tenga que ver con recibir servicio de verdad. Esas son las páginas que más probablemente generan una queja y las que hacen más daño real a un paciente o cliente que intenta pedir ayuda.

Reglas de WCAG que realmente rigen el contenido multilingüe

El Criterio de Éxito 3.1.2, Idioma de las Partes, es la regla de WCAG que habla directamente de las páginas multilingües. Exige que el idioma de cada pasaje o frase sea detectable por el sistema, para que los lectores de pantalla y otras tecnologías de asistencia puedan cambiar automáticamente de motor de pronunciación y síntesis. Este estándar del W3C explica que, sin esto, un lector de pantalla configurado en inglés intentará leer texto en español usando reglas fonéticas del inglés, produciendo un resultado enredado y a veces ininteligible para el Criterio de Éxito 3.1.2.

Ese único requisito técnico carga más peso práctico para los sitios multilingües que casi cualquier otro punto de WCAG, porque determina si la tecnología de asistencia siquiera puede intentar una pronunciación correcta. Otros pocos criterios importan igual de mucho una vez que el 3.1.2 está resuelto:

Consejo profesional: Prueba tus páginas en español con un lector de pantalla configurado con un perfil de voz en español, no solo con el inglés predeterminado. La mayoría de los equipos prueban solo en inglés y nunca se dan cuenta de que la voz sintetizada está destrozando su propio contenido traducido.

La paridad estructural es la pieza que más seguido se pasa por alto. Si tu mensaje de error en inglés dice “Please enter a valid phone number” y enlaza a una página de ayuda, tu versión en español necesita la misma estructura, el mismo enlace y el mismo nivel de claridad. Una traducción más corta o más vaga no es equivalente, aunque sea gramaticalmente correcta.

Un checklist práctico para sitios web multilingües accesibles

Arreglar los problemas de accesibilidad multilingüe funciona mejor cuando el trabajo técnico, de contenido, de UX y de proceso se hace en ese orden. Saltarte la capa técnica significa que cada arreglo de contenido tendrá que rehacerse después.

  1. Configura el atributo lang correctamente. Etiqueta el elemento <html> con el idioma principal de la página, y envuelve cualquier frase integrada en otro idioma con su propio atributo lang, según el Criterio de Éxito 3.1.2.
  2. Confirma la codificación UTF-8 en todo el sitio para que los caracteres acentuados y la puntuación especial se rendericen y se lean correctamente.
  3. Preserva los roles ARIA y el marcado semántico a través de la traducción. Los proveedores de traducción a veces aplanan la estructura HTML cuando mueven el contenido por herramientas de memoria de traducción. Haz que los desarrolladores verifiquen que el marcado sobrevive.
  4. Localiza el texto alternativo, no solo el cuerpo del texto. Cada descripción de imagen necesita su propia traducción, acorde al idioma de la página que la rodea.
  5. Localiza por completo las etiquetas de formulario y los mensajes de error, incluyendo el texto de validación que solo aparece cuando un paciente comete un error.
  6. Proporciona subtítulos y transcripciones para cada idioma que use tu contenido de audio o video.
  7. Ofrece alternativas accesibles a los PDF escaneados o basados en imágenes, ya que un formulario de admisión en español escaneado es ilegible para un lector de pantalla sin importar el idioma.
  8. Revisa el orden de foco y la navegación por teclado en la versión traducida por separado. Los cambios de diseño por cadenas traducidas más largas o más cortas a veces rompen el orden de tabulación aunque la versión en inglés funcione bien.
  9. Mantén la navegación y los controles de cambio de idioma visibles y consistentes en todas las páginas, no solo en la de inicio.
  10. Incluye los requisitos de accesibilidad en los contratos con proveedores y exige documentación antes de publicar.

Consejo profesional: Agrega un punto de control de QA a tu proceso de publicación que bloquee cualquier página traducida hasta que alguien verifique el atributo lang y lo pruebe con un lector de pantalla. Detectar esto antes de publicar sale mucho más barato que arreglarlo después de una queja.

Cómo probar la accesibilidad multilingüe antes de que se vuelva una queja

Los escáneres automáticos detectan muchas cosas: texto alternativo faltante, fallas de contraste, etiquetas de formulario ausentes. Se les escapa casi todo lo específico del idioma. Un escáner no te dirá que el resultado de tu lector de pantalla en español es ininteligible, ni que un mensaje de error traducido perdió su conexión semántica con el campo del formulario que describe. La guía del gobierno es directa sobre este límite y recomienda combinar las revisiones automáticas con auditorías manuales y pruebas con usuarios, en lugar de dejarlas solas.

Las revisiones manuales para páginas multilingües deben incluir:

Las pruebas con usuarios cierran la brecha que las auditorías manuales no alcanzan. Recluta a hablantes nativos con discapacidad para cada idioma y sistema de escritura que tu sitio admita, y haz que intenten tareas reales: agendar una cita, llenar un formulario de admisión, encontrar tu número de teléfono. Algunas organizaciones han enfrentado acciones de cumplimiento que exigen remediar herramientas de terceros y contenido enlazado, lo que es un recordatorio de que los widgets integrados y los portales de proveedores cuentan como parte de tu sitio, no como problema de otro.

Establece un ritmo: revisiones semanales de cualquier página recién publicada o traducida, y una auditoría trimestral completa en cada versión de idioma. Los sitios multilingües se salen de cumplimiento más rápido que los de un solo idioma simplemente porque hay más páginas que mantener sincronizadas.

Fechas de cumplimiento del DOJ y las excepciones que sí aplican

La regla final del DOJ entró en vigor el 24 de junio de 2024, con fechas de cumplimiento escalonadas. Las entidades públicas más grandes (las que atienden a poblaciones de 50,000 o más) deben cumplir antes del 24 de abril de 2026. Las entidades públicas más pequeñas y los gobiernos de distritos especiales tienen más tiempo. Los negocios privados del Título III no están cubiertos directamente por esta regla específica, pero el mismo estándar WCAG 2.1 AA es ahora el punto de referencia que reguladores y tribunales esperan.

Las cinco excepciones que vale la pena recordar:

Si tu organización considera que la conformidad total genera una carga excesiva o una alteración fundamental de tus servicios, documenta el razonamiento específico, el análisis de costos y cualquier adaptación provisional que hayas ofrecido en su lugar. Ese registro escrito es lo que te protege si la decisión llega a cuestionarse.

Mantener la traducción y la accesibilidad alineadas al actualizar contenido

El flujo de trabajo más seguro trata la accesibilidad como un punto de control dentro de tu proceso de localización, no como una limpieza aparte que se hace después.

  1. Corre las revisiones de accesibilidad del idioma de origen antes de que empiece la traducción. Una página en inglés inaccesible produce una página en español inaccesible, solo que con trabajo de más.
  2. Da instrucciones explícitas a los traductores para que preserven la estructura HTML, las etiquetas ARIA y los marcadores de texto alternativo en lugar de reescribir el marcado.
  3. Exige QA de desarrollo en cada página traducida antes de publicarla, revisando los atributos lang y la estructura semántica, no solo el diseño visual.
  4. Exige formatos de archivo accesibles a los proveedores. Un PDF remediado y etiquetado o una alternativa en HTML deberían ser lo establecido por contrato, no una ocurrencia de último momento.
  5. Arma un checklist localizado de QA de accesibilidad con un responsable nombrado que dé el visto bueno antes de que salga cualquier versión de idioma.

El propio checklist de matiz cultural y comunicación de Diazluna recorre el texto traducido, la navegación y las pruebas con tecnología de asistencia con más detalle, por si quieres una plantilla para adaptar.

Publicar un aviso de accesibilidad y atender solicitudes en cualquier idioma

Un aviso de accesibilidad, publicado en cada idioma que ofrezcas, les dice a pacientes y clientes exactamente cómo pedir ayuda si algo de tu sitio no les funciona. Como mínimo, debe incluir un correo de contacto y un número de teléfono, opciones de relé de video o interpretación remota por video cuando aplique, un plazo de respuesta declarado y una descripción clara de cómo enviar una solicitud.

Consejo profesional: Registra cada solicitud de accesibilidad y cómo se resolvió, incluso las simples. Ese registro se vuelve tu mejor prueba de esfuerzo de buena fe si una queja llega a escalar.

El incumplimiento en un segundo idioma acarrea la misma exposición legal que las fallas en inglés, y a veces más, porque la brecha es más fácil de probar. El abogado de un demandante no necesita un argumento complejo para demostrar que una página en español carece de atributos lang o que un formulario traducido no tiene etiquetas accesibles; la falla se ve con herramientas de prueba básicas.

Los negocios del Título III enfrentan demandas privadas y acciones de cumplimiento del DOJ por fallas de comunicación efectiva. Las entidades públicas del Título II enfrentan la misma exposición más el estándar específico WCAG 2.1 AA ahora escrito en la regla federal, con fechas de cumplimiento claras. Los tribunales han tratado cada vez más el ofrecer un idioma como un compromiso: una vez que publicas en español, asumiste la obligación de hacer accesible ese contenido en español, no una versión más ligera de la obligación en inglés.

El costo reputacional tiende a sumarse al legal. Un consultorio dental o un despacho de abogados que se promociona ante clientes hispanos, y luego entrega un sitio web en español que un paciente hispanohablante ciego o con baja visión no puede usar, echa por tierra justamente la confianza que la difusión bilingüe se suponía que iba a construir. Ese daño no aparece en la cifra de un acuerdo, pero sí aparece en la retención de clientes.

Los sitios multilingües también multiplican tu superficie de riesgo. Cada idioma adicional es otro conjunto completo de páginas que pueden salirse de cumplimiento, otro proveedor de traducción cuyo resultado necesita QA, y otra versión de cada formulario y mensaje de error que tiene que mantenerse sincronizada con el original en inglés. Tratar cada idioma como una obligación de accesibilidad totalmente aparte, en lugar de una capa de traducción sobre un solo sitio en cumplimiento, es la mentalidad que de verdad aguanta el escrutinio.

El marcado de idioma más allá de lo básico

El Criterio de Éxito 3.1.2 cubre el requisito central, pero unos cuantos hábitos prácticos van más allá de la letra de la regla. Etiqueta los cambios de idioma en la unidad razonable más pequeña: una sola frase entre comillas en español dentro de un párrafo en inglés necesita su propio atributo lang, no solo una etiqueta a nivel de página.

Pon atención a los cambios de idioma dentro del contenido dinámico: las respuestas de chatbot, los resultados de búsqueda y los comentarios generados por usuarios a menudo mezclan idiomas sin ningún marcado. Si tu sitio detecta automáticamente el idioma del navegador de un paciente y sirve contenido en consecuencia, asegúrate de que el atributo lang se actualice para coincidir con lo que realmente se renderiza, no con lo que el servidor supuso.

Evita depender solo de pistas visuales, como el ícono de una bandera o el nombre de un país, para señalar el idioma. Los pacientes con lector de pantalla necesitan el idioma codificado en el propio marcado, no insinuado por un gráfico que no pueden ver. Y cuando uses un selector de idioma, etiquétalo en ambos idiomas al mismo tiempo, como “Español / English”, para que un paciente que usa tecnología de asistencia en cualquiera de los dos idiomas pueda encontrar y entender el control.

Un detalle que se suele pasar por alto: los atributos lang necesitan códigos de idioma válidos (“es” para español, “en” para inglés), no abreviaturas ni variantes regionales a menos que de verdad necesites distinguir, digamos, el español mexicano del español castellano para fines de pronunciación. Poner mal el código rompe justamente el comportamiento de síntesis que el 3.1.2 existe para habilitar.

Cuatro prácticas de marcado de idioma multilingüe

Manejar la accesibilidad del contenido multilingüe de terceros

Los widgets de agendamiento, los plugins de chat, los procesadores de pago y las plataformas de reseñas integradas suelen estar hechos por alguien más, pero el DOJ y los tribunales han dejado claro que igual caen dentro de tus obligaciones de accesibilidad cuando están en tu sitio. La excepción para el contenido de terceros es más acotada de lo que la mayoría de los equipos supone. Aplica al contenido que de verdad está fuera de tu control, no a una herramienta de proveedor que tú elegiste, integraste y de la que sacas provecho.

Antes de adoptar cualquier widget de terceros para un sitio bilingüe, pregúntale directo al proveedor si su herramienta admite el etiquetado de idioma correcto y si ha sido probada con lectores de pantalla en ambos idiomas. Consigue la respuesta por escrito y mete los requisitos de accesibilidad en el propio contrato en lugar de tratarlo como una garantía de palabra.

Cuando un proveedor no pueda confirmar la accesibilidad multilingüe, prepara una alternativa: un número de teléfono, un correo o un formulario accesible sencillo que logre la misma tarea sin depender de la herramienta de terceros. Esa alternativa protege a pacientes y clientes mientras presionas al proveedor para que lo arregle, o decides cambiar de proveedor por completo.

Audita las herramientas de terceros con el mismo ritmo que tu propio contenido, ya que los proveedores actualizan su software sin depender de tu calendario de publicaciones, y una actualización de su lado puede romper en silencio el comportamiento de accesibilidad que probaste hace seis meses. El enfoque de Diazluna sobre el marketing digital bilingüe toca el tema de evaluar integraciones de terceros para consultorios que hacen malabares con varias herramientas de proveedores en dos idiomas.

Mantener el cumplimiento multilingüe al día mientras cambia el contenido

El cumplimiento no es un proyecto de una sola vez. Cada nueva entrada de blog, formulario actualizado o página de servicio agregada en un segundo idioma es una nueva oportunidad de reintroducir los mismos errores que ya arreglaste una vez. Las organizaciones que tratan la accesibilidad multilingüe como un flujo de trabajo permanente, en lugar de una auditoría terminada, son las que se mantienen en cumplimiento.

Asigna responsabilidad clara. Alguien de tu equipo, o de tu agencia, tiene que encargarse de verificar que el contenido nuevo en español reciba la misma revisión de accesibilidad que el contenido nuevo en inglés, cada vez, sin excepción. Integra esa revisión en tu calendario de contenido en lugar de esperar que alguien se acuerde.

Vigila el crecimiento descontrolado en tu cobertura de idiomas. Agregar un tercer idioma, o pasar de una página de marketing a una experiencia transaccional completa, reinicia tu perfil de riesgo. Trata cada expansión significativa como su propia mini auditoría en lugar de suponer que tu checklist existente cubre automáticamente la nueva superficie.

Por último, mantén tu documentación al día. Si ya registraste decisiones de carga excesiva, el texto del aviso de accesibilidad y resultados de pruebas con usuarios anteriores, actualiza esos registros cada vez que la estructura de tu sitio cambie de forma significativa. La documentación desactualizada echa por tierra el propósito de tenerla. El artículo de Diazluna sobre lo que un sitio web bilingüe significa para el crecimiento explica por qué tratar el acceso al idioma como infraestructura operativa continua, y no como un checklist de lanzamiento, tiende a dar mejores resultados a largo plazo para los consultorios que atienden a clientes hispanos.

Lo que de verdad te enseña trabajar con recepciones bilingües

La falla más común no es la mala traducción. Es el etiquetado de idioma incompleto, los PDF que nadie se acordó de remediar y las etiquetas de formulario en español que después de seis meses de ediciones ya no coinciden con sus contrapartes en inglés. Esas brechas se acumulan calladas hasta que un paciente o cliente choca con una y no puede avanzar.

Lo que de verdad reduce la pérdida de clientes es combinar la remediación de accesibilidad con el lado operativo: un sitio web bilingüe que se mantiene preciso, una función de recepción que responde en el idioma correcto a la hora correcta, y un canal de WhatsApp que no obliga a nadie a cambiar de herramienta a mitad de la conversación. Arregla el código, pero también arregla el flujo de trabajo a su alrededor. Para plantillas paso a paso, la guía del sitio web en español para despachos de abogados desglosa cómo se ve eso en la práctica para un sitio de servicios profesionales.

— Francisco

Una recepción bilingüe que también cubre la brecha de acceso

La remediación de accesibilidad arregla el código de tu sitio web y es clave para impulsar la inclusión y el impacto en SEO. No contesta el teléfono a las 9 p. m. en español, ni atrapa el mensaje de WhatsApp de un paciente que no pudo llenar tu formulario en línea. Diazluna está hecho para esa brecha: un sitio web bilingüe totalmente optimizado combinado con una recepcionista de IA disponible 24/7 que domina el español y el inglés, más integración con WhatsApp, para que no pierdas a ningún cliente solo porque el idioma o el canal no estaban ahí cuando los necesitaba.

Diazluna

Esto no es afirmar que Diazluna por sí solo hace que tu sitio cumpla legalmente, ese trabajo sigue pasando por el checklist de arriba. Lo que sí hace es asegurar que el lado humano del acceso al idioma, las llamadas, los mensajes, las preguntas fuera de horario, se atienda en ambos idiomas sin que tu consultorio tenga que hacer malabares con tres proveedores distintos para lograrlo. Los planes empiezan con Solo Sitio, un paquete básico de sitio web bilingüe adecuado para negocios pequeños, y el paquete completo Sitio + María, que agrega la recepcionista de IA, está disponible como una opción de nivel superior. Si quieres una mirada enfocada a dónde tiene brechas tu recepción bilingüe, revisa los paquetes actuales en Diazluna y pide un recorrido de lo que le va a tu consultorio.

Dónde verificar esta información directamente

Para las fuentes legales y técnicas principales detrás de esta guía, ve directo a las publicaciones gubernamentales en lugar de a los resúmenes secundarios. La Guía de Cumplimiento para Entidades Pequeñas del DOJ cubre la adopción de WCAG 2.1 AA y los plazos en lenguaje sencillo. La guía sobre comunicación efectiva y la guía general de accesibilidad web de ADA.gov cubren las obligaciones y las recomendaciones de prueba. La página del W3C sobre Idioma de las Partes explica el estándar técnico detrás del Criterio de Éxito 3.1.2. Para el texto regulatorio completo y las fechas de cumplimiento, consulta la regla final del Federal Register y el PDF de la regla web del DOJ.

Fuentes

Preguntas frecuentes

¿Cuáles son los requisitos de accesibilidad web de la ADA para 2026?

Las entidades públicas cubiertas por el Título II deben cumplir con WCAG 2.1 Nivel AA para el contenido web y las apps móviles, y las entidades más grandes deben cumplir antes del 24 de abril de 2026 según la regla final del DOJ. Los negocios privados bajo el Título III no tienen esa regla específica, pero las obligaciones de comunicación efectiva siguen aplicando, y WCAG 2.1 AA es el estándar que citan reguladores y tribunales.

¿Qué lugares están exentos del cumplimiento de la ADA?

La regla del DOJ contempla cinco excepciones acotadas: contenido archivado, documentos convencionales preexistentes (a menos que se soliciten), contenido de terceros fuera del control de la entidad, contenido individualizado protegido con contraseña y publicaciones preexistentes en redes sociales. Las páginas activas, públicas y transaccionales como formularios de citas y portales de admisión no están exentas.

¿Aplica la ADA fuera de Estados Unidos?

No. La ADA es una ley federal de EE. UU. y aplica solo a las entidades y el contenido que operan en Estados Unidos; otros países tienen sus propias leyes de accesibilidad, como las directivas de accesibilidad de la UE. Si tu consultorio atiende a pacientes en el extranjero, revisa por separado los requisitos de accesibilidad específicos de ese país.

Por ahora no. La regla final del DOJ adoptó específicamente WCAG 2.1 Nivel AA como el estándar técnico del Título II. Seguir estándares más nuevos cuando sea práctico es una buena costumbre, pero 2.1 AA sigue siendo la versión que cita la regla federal actual.

¿Cuánto cuesta Diazluna para un sitio web bilingüe?

Diazluna ofrece un modelo de suscripción que empieza con un plan básico de sitio web bilingüe y paquetes adicionales que incluyen servicios de recepcionista de IA bilingüe. Para los detalles de precios más actuales, visita el sitio web oficial de Diazluna. Los precios completos vigentes y el nivel Sitio + María Pro aparecen en el sitio de Diazluna.

Recomendados