En la pantalla del teléfono aparece una alerta de tormenta a las seis y doce de la tarde. Está escrita en castellano, pide evitar los caminos próximos al torrente y enlaza a un mapa que tarda en cargar. En un pueblo donde el catalán es la lengua de las conversaciones cotidianas, muchas personas no abren ese enlace: la cobertura se corta, la batería ya va justa y el aviso parece una de tantas notificaciones administrativas. A las siete, cuando la lluvia obliga a desviar el autobús escolar, una vecina recibe una llamada de su hermana y se entera de que el paso bajo la carretera está cerrado. La información existía, pero no había llegado como información utilizable.
No se trata de decidir que una lengua vale más que otra ni de imaginar que toda persona rural vive desconectada. Se trata de reconocer un detalle decisivo: un mensaje público no cumple su función al ser emitido. La cumple cuando quien necesita actuar puede entenderlo, recibirlo a tiempo y verificar qué debe hacer sin sortear obstáculos adicionales. Una alerta diseñada para la conexión, el idioma y la experiencia de la mayoría puede ser técnicamente correcta y, a la vez, dejar expuesta a una parte del territorio. La desigualdad no llega después del sistema; puede viajar dentro de cada decisión aparentemente menor sobre formato, peso o canal.
La alerta no es solo un texto#
En una situación de riesgo, la información compite con cosas muy concretas: el ruido de una cocina, una persona mayor que no usa aplicaciones, una pantalla con poca cobertura, el cuidado de niños, el trabajo de campo y la incertidumbre sobre si el aviso afecta realmente a ese valle. Por eso traducir una frase al final del proceso no basta. La versión en catalán ha de aparecer con la misma prioridad, en un lenguaje reconocible y junto a indicaciones locales comprensibles. Decir “evite las zonas inundables” ofrece menos ayuda que señalar el acceso concreto, el horario previsto y una alternativa segura cuando esa información está disponible.
En una situación de riesgo, la información compite con cosas muy concretas: el ruido de una cocina, una persona mayor que no usa aplicaciones, una pantalla con poca cobertura, el cuidado de niños, el trabajo de campo y la incertidumbre sobre si el aviso afecta realmente a ese valle.
Tampoco toda accesibilidad es lingüística. Una aplicación con mapas animados, vídeos de reproducción automática y avisos que exigen crear una cuenta convierte una comunicación urgente en una prueba de paciencia. Si la señal cae antes de terminar la carga, el diseño ha trasladado la responsabilidad al destinatario: deberá probar de nuevo, buscar datos, llamar a alguien o resignarse a no saber. En una emergencia, pedir esas maniobras es una forma de repartir de manera desigual el tiempo y el riesgo. El bajo consumo no es una versión pobre del servicio; es una condición para que el servicio funcione en circunstancias reales.
El caso de la tormenta permite distinguir entre redundancia y ruido. Recibir el mismo aviso en una app, una web y una cuenta de redes sociales no ayuda mucho si las tres vías dependen del mismo teléfono con datos. En cambio, una combinación de mensaje breve, página ligera que se abre sin registro, emisora local, tablón municipal y red de llamadas de entidades cercanas crea rutas diferentes hacia la misma decisión. Ningún canal debe inventar instrucciones distintas. Todos deben remitir a una fuente coordinada, indicar la hora de actualización y dejar claro qué se conoce y qué está siendo confirmado.
Diseñar antes de que empiece la emergencia#
La pregunta útil no es “¿podemos añadir una traducción si ocurre algo?”, sino “¿quién queda fuera cuando el aviso se prepara de esta manera?”. Para responderla conviene reunir, antes de la temporada de tormentas, a personas que conocen los recorridos, las lenguas de uso y las limitaciones de conectividad. Pueden participar la radio municipal, asociaciones de familias, equipos de atención primaria, cooperativas agrarias, bibliotecas y quienes organizan transporte. No se les pide que validen un producto terminado; se les pide que describan cómo se entera la gente de las cosas cuando falla el canal habitual.
Ese trabajo puede convertirse en un mapa sencillo de comunicación. No hace falta recolectar datos personales ni publicar quién recibe ayuda. Basta con identificar lugares donde la cobertura es irregular, edificios que concentran a personas vulnerables, horas en que los desplazamientos son más frecuentes y grupos que pueden retransmitir una instrucción comprobada. El mapa debe revisarse con cuidado: una comunidad no es una lista de carencias. Hay personas bilingües que prefieren catalán, otras que leen mejor castellano y otras que necesitan audio, pictogramas o una llamada. Diseñar para la pluralidad no consiste en asignar una única etiqueta a cada pueblo.
También hay que definir quién autoriza y actualiza cada mensaje. En el primer minuto de un episodio meteorológico no es razonable discutir quién puede corregir una calle mal nombrada o si una frase debe adaptarse. Un protocolo previo puede reservar plantillas breves, glosarios locales y responsables claros para cada canal. La plantilla no sustituye el juicio: deja espacio para una instrucción concreta, una hora y una fuente. Su valor está en evitar que el mensaje dependa de que una sola persona recuerde, bajo presión, todas las formas de acceso necesarias.
Canales comunitarios no significa cargar el trabajo sobre voluntarios#
Una red comunitaria puede salvar minutos decisivos, pero no debe convertirse en una excusa para que instituciones públicas abandonen su obligación de informar. La radio local, una asociación vecinal o una cooperativa pueden ampliar el alcance porque ya poseen relaciones de confianza. Necesitan recibir la información oficial con antelación suficiente, una manera rápida de resolver dudas y una señal inequívoca cuando algo cambia. No deben asumir la tarea de interpretar datos confusos ni decidir si es seguro difundir un rumor que llega por mensajería.
En el pueblo imaginado, la emisora podría interrumpir su programación con un boletín de treinta segundos en catalán y castellano. El texto diría qué camino evitar, hasta qué hora rige el aviso y dónde consultar una actualización por llamada telefónica. Un grupo de apoyo podría avisar a personas sin smartphone usando una lista acordada y protegida. La escuela podría entregar por la mañana una nota sobre el protocolo de regreso si el pronóstico empeora. Son piezas diferentes, no sustitutos de una infraestructura robusta. Cada una ofrece una puerta adicional sin obligar a nadie a descargar una aplicación.
La confianza exige además que el canal pueda admitir incertidumbre. Si aún no se sabe si una pasarela estará cerrada, el mensaje puede decirlo y explicar cuándo habrá una nueva comprobación. Una falsa certeza se propaga deprisa y después debilita los avisos posteriores. Un lenguaje claro no es un lenguaje tajante a cualquier precio. Es aquel que distingue una orden inmediata, una recomendación prudente y un dato pendiente, para que la comunidad sepa qué tipo de respuesta corresponde a cada situación.
Probar la exclusión, no solo la plataforma#
Los equipos suelen probar si una aplicación no se bloquea y si el botón de enviar funciona. Esas comprobaciones son necesarias, pero responden a una pregunta estrecha: si el sistema opera en condiciones ideales. La prueba de exclusión pregunta otra cosa: si una persona con una tarifa limitada, una pantalla antigua, una lengua distinta o una conexión intermitente logra comprender y actuar. Para hacerla no hace falta recrear una catástrofe. Se puede ensayar un aviso de lluvia con consentimientos claros, observando dónde se interrumpe la experiencia y qué explicación falta.
Conviene medir tiempos, no solo clics. ¿Cuántos minutos tardó una familia en saber que el autobús cambia de ruta? ¿La página ligera abrió con una conexión lenta? ¿El audio fue entendible sin auriculares? ¿La versión catalana era visible desde la primera pantalla o quedaba escondida tras un menú? ¿Alguien confundió una advertencia comarcal con una orden de evacuación? Las respuestas no deben servir para calificar a quienes participaron, sino para reparar el diseño. Si cinco personas tropiezan en el mismo punto, el problema no es que cinco personas “no sepan usar” el sistema.
La revisión también debe buscar efectos no previstos. Un mensaje que solicita compartir ubicación puede ayudar a una brigada, pero excluir a quien no quiere o no puede hacerlo. Una lista pública de hogares atendidos puede facilitar coordinación y, al mismo tiempo, revelar situaciones sensibles. La accesibilidad no autoriza a extraer más datos de quienes ya afrontan una barrera. Cada función debe justificar qué información necesita, durante cuánto tiempo y quién puede verla. Proteger la privacidad forma parte de que las personas se atrevan a usar el canal.
Una obligación que se puede mantener#
La comunidad rural del ejemplo no necesita una solución espectacular. Necesita que la alerta llegue en catalán y castellano, que pueda leerse con pocos datos, que una llamada o la radio confirme lo esencial y que haya una forma visible de corregir errores. Eso requiere presupuesto para traducción y mantenimiento, acuerdos con medios locales, formación de personal y pruebas repetidas. Requiere también aceptar que algunos avisos no alcanzarán a toda la población al primer intento y que esa realidad obliga a mejorar, no a culpar a quien se quedó fuera.
El siguiente paso puede ser modesto y verificable. Antes del próximo episodio de lluvia, una administración puede publicar una versión de emergencia de menos de 100 kilobytes, acordar dos locuciones cortas con la radio y convocar una prueba con residentes que usan dispositivos y lenguas distintas. Al terminar, debería compartir qué falló, qué se corrigió y cuándo repetirá el ejercicio. Así, informar deja de ser el gesto de emitir una alerta y se convierte en una responsabilidad por las condiciones que permiten recibirla. Una democracia informada no se mide por cuántos mensajes envía, sino por cuántas personas pueden convertirlos en una decisión segura.
