Inclusión y accesibilidad en la experiencia ciudadana: la barrera invisible

Una madre con discapacidad visual intenta renovar el pasaporte de su hijo desde una aplicación gubernamental. El formulario no lee bien con su lector de pantalla, el captcha exige distinguir letras borrosas y el botón de "confirmar" desaparece cuando activa el modo de alto contraste. No abandona el trámite por desinterés. Abandona porque el sistema, sin decirlo, decidió que ella no era el usuario para el que se diseñó.

Esa es la tesis de este artículo: la inclusión no es una casilla de cumplimiento normativo, es una decisión de diseño que determina quién puede ejercer sus derechos como ciudadano y quién se rinde antes de terminar el formulario. Cuando un gobierno diseña un servicio "para el ciudadano promedio", en realidad diseña para nadie en particular, y excluye silenciosamente a millones de personas reales: mayores, personas con discapacidad, migrantes sin dominio del idioma oficial, personas con baja alfabetización digital. La accesibilidad no es un módulo que se añade al final de un proyecto. Es la arquitectura de elección que decide, touchpoint por touchpoint, quién completa el trámite y quién queda fuera del sistema.

¿Qué significa realmente la inclusión en la experiencia ciudadana?

La inclusión en la experiencia ciudadana significa diseñar servicios públicos que funcionen para el rango completo de capacidades humanas —visuales, auditivas, motoras, cognitivas, lingüísticas y de conectividad— sin obligar al ciudadano a pedir una excepción, una llamada telefónica o la ayuda de un familiar para acceder a un derecho básico. No es un programa paralelo para "personas con necesidades especiales": es el estándar mínimo de cualquier servicio que se llame público.

La Organización Mundial de la Salud estima que más de 1.300 millones de personas —alrededor del 16% de la población mundial— viven con alguna forma de discapacidad significativa, según su ficha informativa sobre discapacidad actualizada en 2023. Eso no es un nicho. Es una de cada seis personas que hacen fila en una oficina de atención, llaman a un centro de contacto o intentan navegar un portal de trámites. Diseñar sin pensar en ellas no es un descuido menor: es diseñar mal para una sexta parte de la población a la que se sirve.

¿Por qué la accesibilidad no es un tema de cumplimiento, sino de fricción?

Porque el cumplimiento normativo pregunta "¿pasamos la auditoría?" y la experiencia ciudadana pregunta "¿pudo esta persona completar el trámite hoy, sola, sin ayuda?". Son preguntas distintas y solo la segunda importa al final del día. Un portal puede cumplir técnicamente con los estándares de contraste de color y seguir siendo inutilizable para alguien con temblor motor que no logra hacer clic en un botón de cuatro milímetros.

Richard Thaler, economista del comportamiento y premio Nobel, y el jurista Cass Sunstein distinguieron hace años entre la fricción que protege —la que hace pensar dos veces antes de una decisión irreversible— y la fricción que solo estorba. Sunstein llevó esa idea un paso más allá en su libro Sludge (MIT Press, 2021), donde documenta cómo los trámites administrativos innecesariamente complejos —formularios repetitivos, verificaciones redundantes, lenguaje jurídico impenetrable— funcionan como un impuesto invisible sobre quienes menos recursos tienen para pagarlo: tiempo, paciencia, capacidad cognitiva o simplemente vista aguda.

Ese "sludge" no afecta a todos por igual. La misma pantalla con texto pequeño, jerga técnica y un solo canal de contacto es una molestia menor para un ciudadano de 30 años con buena vista y conexión rápida, y una barrera infranqueable para uno de 70 años con baja visión y datos móviles limitados. La fricción no es neutral: golpea con más fuerza a quien ya tiene menos margen.

¿Qué errores cometen los gobiernos al diseñar para "el ciudadano promedio"?

El error de fondo es tratar la accesibilidad como una capa que se añade después de decidir el diseño "principal", en lugar de tratarla como el punto de partida. En la práctica, esto se traduce en patrones que se repiten en portales de gobierno electrónico de toda la región:

• Un solo canal como única puerta de entrada. Digitalizar un trámite y cerrar la ventanilla física asume que todos los ciudadanos tienen dispositivo, conectividad estable y confianza digital. No es así, y menos en zonas rurales o entre la población mayor.
• Lenguaje administrativo en lugar de lenguaje humano. Formularios redactados por y para abogados, no para la persona que intenta renovar una licencia entre turno de trabajo y recoger a los hijos.
• Accesibilidad tratada como funcionalidad opcional. Lectores de pantalla que no reconocen campos clave, subtítulos ausentes en videos explicativos, contraste insuficiente en botones críticos.
• Verificación de identidad hostil por diseño. Captchas visuales sin alternativa auditiva, tiempos de sesión demasiado cortos para alguien que necesita más tiempo para leer o escribir.
• Ausencia de pruebas con usuarios reales diversos. El equipo de producto valida el flujo consigo mismo, no con una muestra que incluya personas mayores, con discapacidad o con baja alfabetización digital.

Ninguno de estos errores nace de mala fe. Nacen de diseñar mirando al usuario más fácil de imaginar: joven, con smartphone nuevo, buena vista y paciencia infinita. Ese ciudadano existe, pero no representa a la mayoría de quienes dependen de un servicio público.

¿Cómo ayuda la economía del comportamiento a diseñar servicios inclusivos?

La arquitectura de elección —el concepto que Thaler y Sunstein popularizaron en Nudge (2008)— parte de una premisa incómoda para cualquier diseñador de servicios: no existe un diseño neutral. Cada decisión sobre qué opción aparece primero, qué campo es obligatorio, qué formato de archivo se acepta o qué canal es el predeterminado, empuja al ciudadano en una dirección u otra. La pregunta correcta nunca es "¿debemos influir en la conducta del ciudadano?" —ya lo estamos haciendo— sino "¿en qué dirección estamos empujando, y a quién dejamos atrás?".

Aplicado a la inclusión, esto tiene consecuencias prácticas muy concretas:

• Los valores por defecto (defaults) deciden quién queda fuera. Si el canal predeterminado de notificación es un SMS con enlace a un PDF, un ciudadano con discapacidad visual queda excluido por defecto, no por elección. Cambiar el default a un formato accesible no cuesta más y redefine quién puede participar.
• La carga cognitiva es un costo real, no una molestia menor. Cada paso adicional, cada campo confuso, cada decisión que el ciudadano debe tomar sin ayuda consume una reserva limitada de atención y confianza. Reducir pasos no es solo eficiencia operativa: es accesibilidad cognitiva.
• El lenguaje simple es una intervención de comportamiento, no una concesión estética. Sustituir "en caso de incumplimiento de los requisitos estipulados en el apartado 4.2" por "si te falta un documento, te avisaremos así" reduce el abandono porque reduce el esfuerzo mental necesario para decidir el siguiente paso.

Este es exactamente el terreno donde trabaja la economía del comportamiento aplicada a la experiencia: no se trata de manipular al ciudadano, sino de reconocer que el diseño ya lo está influyendo, y hacerlo de forma que reduzca la exclusión en lugar de profundizarla.

¿Cómo se mide realmente si un servicio público es inclusivo?

Se mide observando, no asumiendo. Las pautas técnicas de accesibilidad web —las Pautas de Accesibilidad para el Contenido Web (WCAG) del World Wide Web Consortium (W3C)— son el punto de partida obligatorio para cualquier portal de gobierno electrónico: contraste de color, navegación por teclado, texto alternativo en imágenes, compatibilidad con lectores de pantalla. Cumplirlas es necesario. No es suficiente.

Lo que la auditoría técnica no captura es la experiencia vivida: cuánto tiempo tarda realmente un ciudadano mayor en completar un trámite, en cuántos puntos duda, dónde llama por teléfono porque no confía en el botón que está viendo. La investigación de usabilidad del Nielsen Norman Group sobre usuarios mayores documenta de forma consistente que este segmento necesita más tiempo, comete más errores de navegación y abandona antes ante mensajes de error poco claros —hallazgos que cualquier equipo de gobierno digital debería tratar como estándar de diseño, no como excepción a acomodar.

Por eso el instrumento más honesto sigue siendo observar a personas reales, con capacidades y contextos distintos, intentando completar el trámite sin ayuda del equipo que lo diseñó. Un ejercicio de mystery shopping diseñado con personas que representan discapacidad visual, auditiva, motora o simplemente baja fluidez digital revela en una tarde lo que meses de reportes internos de satisfacción nunca muestran: el punto exacto donde el trámite se rompe para alguien que no es el usuario imaginado por el equipo de producto.

¿Cómo se construye un servicio público verdaderamente inclusivo? Una secuencia de trabajo

La inclusión no se decreta con una política interna; se construye con una secuencia deliberada de trabajo, repetida servicio por servicio. Esta es la que funciona en la práctica:

1. Mapear el journey completo, no solo el flujo digital. Identificar cada etapa, paso y punto de contacto —presencial, telefónico, digital y por intermediarios— desde la perspectiva de personas con distintas capacidades y niveles de confianza tecnológica.
2. Segmentar por barrera real, no por dato demográfico. "Persona mayor de 65 años" dice poco; "persona que necesita tiempo extendido de lectura y prefiere confirmación telefónica" dice todo lo necesario para rediseñar el paso.
3. Auditar contra estándares técnicos reconocidos. Aplicar WCAG como mínimo no negociable en cualquier canal digital, y su equivalente de lenguaje claro y señalización física en canales presenciales.
4. Rediseñar los valores por defecto antes que las opciones adicionales. Preguntar primero "¿qué le pasa a quien nunca cambia ninguna configuración?" antes de añadir un modo accesible opcional que casi nadie encontrará.
5. Probar con personas reales, no con el equipo de diseño. Ninguna validación interna sustituye a observar a un ciudadano con la barrera real intentando completar el trámite sin guía.
6. Medir el abandono por segmento, no solo el promedio. Una tasa de finalización del 92% puede esconder un 40% de abandono entre usuarios con discapacidad si nadie separa los datos.
7. Corregir el punto de quiebre y volver a probar. La inclusión es un proceso iterativo, no un proyecto que se cierra con un certificado.

Este enfoque exige tratar cada trámite como un producto que se diseña, se prueba y se mejora —el mismo rigor que aplica un buen servicio de diseño de servicios a cualquier experiencia comercial, aplicado ahora a un contexto donde el "cliente" no puede simplemente elegir a un competidor: depende de que ese único servicio funcione.

¿Qué ocurre cuando la inclusión falla en un momento crítico?

Falla de forma silenciosa, y esa es la parte peligrosa. Un ciudadano que no puede completar un trámite de salud, pensión o identidad no suele quejarse en una encuesta de satisfacción: simplemente desaparece del sistema, pide ayuda a un tercero informal, o renuncia al derecho que estaba buscando ejercer. No hay ticket de soporte que capture esa pérdida, porque el ciudadano nunca llegó a generar uno.

Estos son los momentos de la verdad más peligrosos de cualquier servicio público: no el punto donde el ciudadano se queja, sino el punto donde se va sin dejar rastro. El principio del pico y el final (peak-end rule) de Daniel Kahneman explica por qué esto importa incluso para quienes sí logran completar el trámite: la experiencia se recuerda por su momento más intenso y por cómo termina, no por su promedio. Si el final de un trámite de discapacidad es una llamada de veinte minutos en espera para confirmar algo que el formulario ya pedía, ese es el recuerdo que el ciudadano se lleva del Estado entero, no solo de ese trámite.

La inclusión, entendida así, deja de ser un tema de derechos humanos abstracto —aunque lo sea— y se convierte en una cuestión de diseño de journey concreto: qué pasos existen, en qué orden, con qué alternativas, y qué pasa cuando algo sale mal. Un buen mapeo de journeys ciudadanos que incorpore explícitamente a personas con discapacidad, adultos mayores y hablantes no nativos del idioma oficial no es un ejercicio adicional de equidad: es la única forma de ver el servicio completo, tal como realmente opera para todos los que dependen de él.

¿Por dónde empieza un equipo de gobierno con recursos limitados?

No hace falta un rediseño total del portal nacional para empezar a cerrar la brecha. La secuencia realista es más modesta y más honesta:

• Elegir un solo trámite de alto volumen y alto impacto —una pensión, un subsidio, un documento de identidad— y auditar su journey completo con foco en las barreras reales, no en el checklist técnico.
• Corregir primero los valores por defecto: canal de notificación, formato de documento, tiempo de sesión. Son los cambios de menor costo y mayor efecto.
• Habilitar siempre una alternativa humana —teléfono, ventanilla, intermediario comunitario— para quien no puede completar el paso digital, sin penalizar ese camino con tiempos de espera desproporcionados.
• Medir el abandono desagregado antes y después del cambio, no solo la satisfacción promedio.

Evaluar la madurez de estas capacidades de forma estructurada —no intuitiva— también ayuda a priorizar dónde invertir primero. Herramientas como la evaluación de madurez de experiencia permiten a un equipo de gobierno digital ubicar con precisión en qué building blocks está más rezagado antes de comprometer presupuesto en un rediseño mayor.

El diseño inclusivo no es caridad institucional, es infraestructura cívica

Un Estado que diseña solo para su ciudadano más cómodo no está siendo neutral: está decidiendo, touchpoint por touchpoint, quién tiene acceso pleno a sus derechos y quién debe pedir ayuda para conseguir lo mismo. La accesibilidad bien hecha no ralentiza el sistema ni encarece el proyecto de forma desproporcionada; lo que encarece de verdad es rehacer un portal entero cinco años después, cuando la exclusión ya generó litigios, quejas públicas o simplemente una pérdida silenciosa de confianza en la administración digital.

La pregunta que debería guiar cada decisión de diseño en un servicio público no es "¿esto cumple la norma?", sino "¿quién no puede hacer esto sola, hoy, y qué vamos a hacer al respecto?". Responder eso con honestidad, servicio por servicio, es la diferencia entre un gobierno digital que moderniza trámites y uno que de verdad amplía derechos.