En este artículo
En resumen: la accesibilidad web es la condición de que cualquier persona, incluidas las personas con discapacidad, pueda percibir, entender, navegar e interactuar con un sitio. El estándar internacional son las WCAG (Web Content Accessibility Guidelines) del W3C, organizadas en cuatro principios: perceptible, operable, comprensible y robusto, con niveles de conformidad A, AA y AAA. En Colombia, la Resolución 1519 de 2020 de MinTIC incluye un anexo de accesibilidad web que las entidades deben aplicar en sus portales.
Un ciudadano no debería necesitar un mouse, distinguir un color específico ni interpretar una imagen sin texto para solicitar un certificado, consultar una convocatoria o radicar una petición. En la accesibilidad web para entidades públicas, esa premisa tiene consecuencias directas sobre el diseño, la arquitectura, los flujos editoriales y la continuidad operativa de los canales institucionales.
Para una entidad, la accesibilidad no es una capa visual que se agrega antes de publicar. Es una condición de calidad del servicio digital. Cuando se aborda tarde, aparecen correcciones costosas en plantillas, componentes, documentos, formularios e integraciones. Cuando se incorpora desde la definición del producto, permite ofrecer servicios más claros, medibles y sostenibles para toda la ciudadanía.
La accesibilidad es una responsabilidad de servicio
Los canales digitales institucionales concentran trámites, información de interés público, mecanismos de participación y atención ciudadana. Si una persona usuaria de lector de pantalla no puede entender un formulario, si el teclado no permite completar una solicitud o si un video esencial no tiene subtítulos, el problema no es solamente técnico: el acceso al servicio queda limitado.
En Colombia, los lineamientos de Gobierno Digital y las exigencias aplicables a las entidades públicas establecen un marco que debe revisarse frente a la normativa vigente y al contexto de cada canal. La referencia técnica habitual es WCAG 2.1 en nivel AA, incorporada en los criterios de accesibilidad definidos para sitios web institucionales. Sin embargo, cumplir una lista de verificación no garantiza por sí solo una experiencia utilizable.
Una plataforma puede superar validaciones automáticas y, aun así, presentar barreras críticas. Por ejemplo, un campo puede tener una etiqueta técnica correcta, pero una instrucción ambigua; un menú puede recibir foco con el teclado, pero recorrer decenas de opciones antes de llegar al contenido; un PDF puede estar publicado, pero ser imposible de interpretar con tecnologías de asistencia. La evaluación debe combinar conformidad técnica, revisión editorial y pruebas de uso.
Qué debe resolver una arquitectura accesible
La accesibilidad se define en decisiones que suelen tomarse antes de escribir una línea de contenido. La arquitectura de información debe organizar los servicios según las necesidades reales de las personas, no según el organigrama interno. Una navegación predecible, jerarquías de encabezados coherentes y rutas claras reducen carga cognitiva para todos los públicos.
También depende de un sistema de diseño con componentes reutilizables. Botones, alertas, acordeones, tablas, tarjetas, pestañas y formularios deben construirse con comportamiento consistente, estados visibles y semántica correcta. Si cada equipo o proveedor implementa estos elementos de manera aislada, la entidad multiplica sus riesgos de incumplimiento y hace más difícil el mantenimiento.
Formularios que permiten completar el trámite
Los formularios son uno de los puntos más sensibles. Un campo obligatorio identificado solo con color, un mensaje de error ubicado lejos del campo afectado o un captcha inaccesible pueden interrumpir un proceso esencial. La solución exige etiquetas explícitas, instrucciones comprensibles, validaciones anunciadas de forma adecuada y una secuencia de foco lógica.
No todos los formularios requieren el mismo nivel de complejidad. Un formulario de contacto puede resolverse con reglas simples; una inscripción, un pago o una radicación con documentos adjuntos requiere analizar estados, tiempos de sesión, recuperación ante errores y confirmaciones verificables. El criterio debe ajustarse al riesgo y a la relevancia del servicio, sin renunciar a los principios de accesibilidad.
Contenidos que conservan su significado
La plataforma puede estar bien construida y perder accesibilidad por la publicación cotidiana. Los textos alternativos genéricos, como “imagen 1”, no aportan información. Las tablas usadas para simular columnas, los títulos sin jerarquía y los enlaces con textos como “haga clic aquí” dificultan la comprensión y la navegación asistida.
Esto demanda flujos editoriales claros. Quienes publican deben contar con plantillas que orienten el uso correcto de encabezados, imágenes, enlaces, documentos y multimedia. Además, el gestor de contenidos debe prevenir errores frecuentes cuando sea posible, en lugar de trasladar toda la responsabilidad a la memoria del editor.
En plataformas Drupal, por ejemplo, los tipos de contenido, los campos requeridos y las reglas de validación pueden ayudar a que el texto alternativo, los subtítulos o los títulos descriptivos formen parte del proceso de publicación. La tecnología aplicada con criterio de arquitectura y continuidad reduce la dependencia de revisiones manuales tardías.
Accesibilidad web para entidades públicas: cómo evaluarla
Una auditoría útil no se limita a ejecutar herramientas automáticas. Estas detectan problemas relevantes, como contrastes insuficientes, atributos ausentes o estructuras mal definidas, pero no identifican por completo la calidad de una instrucción ni la lógica de un recorrido ciudadano.
El alcance debe priorizar las páginas y transacciones de mayor impacto: inicio, buscador, navegación, páginas de trámites, formularios, autenticación, pagos cuando aplique, documentos descargables y módulos integrados de terceros. Es preferible evaluar a fondo los recorridos críticos que obtener un inventario extenso sin capacidad de corrección.
Una revisión integral suele comprobar, como mínimo, los siguientes aspectos:
- Navegación completa mediante teclado, con foco visible y orden consistente.
- Compatibilidad de la estructura y los mensajes con lectores de pantalla.
- Contraste, redimensionamiento de texto y ausencia de información dependiente solo del color.
- Semántica HTML, encabezados, regiones de página y nombres accesibles de controles.
- Formularios, errores, contenidos multimedia y documentos descargables.
Los hallazgos deben registrarse con evidencia, severidad, criterio afectado, componente responsable y recomendación de corrección. Un reporte que solo enumera errores no ayuda a priorizar. Una matriz trazable permite decidir qué se corrige de inmediato, qué requiere rediseño y qué depende de un tercero o de una actualización tecnológica.
El reto de las plataformas heredadas y las integraciones
Muchas entidades operan sobre portales que han crecido por módulos, micrositios y proveedores sucesivos. En esos escenarios, es frecuente encontrar plantillas duplicadas, componentes sin mantenimiento, librerías desactualizadas y formularios incrustados desde sistemas externos. La accesibilidad no se resolverá con una modificación aislada de estilos.
Conviene establecer una línea base: inventariar plantillas y componentes, identificar servicios críticos, revisar dependencias y determinar qué barreras pertenecen al núcleo de la plataforma, a contenidos específicos o a integraciones. Esta distinción protege el presupuesto y evita atribuir al equipo editorial problemas que pertenecen a una arquitectura deficiente.
Las integraciones merecen atención especial. Un chat, una herramienta de agendamiento, un visor documental o un sistema de pagos puede convertirse en la principal barrera del recorrido. La entidad debe incorporar criterios de accesibilidad en sus procesos de selección, contratación y aceptación técnica. Si un tercero no puede corregir un problema crítico, será necesario evaluar alternativas, mecanismos complementarios o cambios en el flujo de servicio.
Convertir el cumplimiento en una capacidad operativa
La accesibilidad se deteriora si se maneja como un proyecto de una sola vez. Cambios de contenido, nuevas campañas, actualizaciones de módulos y rediseños parciales pueden introducir barreras en cuestión de semanas. Por eso, el modelo de gestión debe incluir controles antes de publicar y seguimiento después del despliegue.
Una práctica efectiva combina un sistema de diseño accesible, criterios de aceptación para desarrollo, guías editoriales, pruebas en ambientes de calidad y auditorías periódicas sobre los recorridos de mayor uso. También requiere responsables definidos: comunicaciones cuida la calidad editorial, tecnología mantiene componentes e infraestructura, y las áreas dueñas del servicio validan que el trámite pueda completarse sin barreras.
La automatización puede aportar valor en controles recurrentes, especialmente para detectar patrones de contraste, atributos o estructura. Pero debe operar como apoyo a la gobernanza, no como sustituto de la revisión experta. Las decisiones relevantes deben ser auditables y medibles: qué se encontró, quién lo corrige, cuándo se valida y qué servicio mejora para la ciudadanía.
Diseñar para la diversidad mejora el canal completo
Una interfaz accesible suele ser también más comprensible en pantallas pequeñas, conexiones lentas y contextos de estrés. Los subtítulos apoyan a quien consulta un video sin audio; las instrucciones precisas reducen solicitudes al centro de contacto; una estructura semántica consistente favorece la indexación y facilita el mantenimiento.
El objetivo no es convertir la accesibilidad en una lista de excepciones ni en un requisito que frene la evolución digital. Se trata de incorporarla como una disciplina de calidad en cada decisión sobre contenido, experiencia, desarrollo e integración. Cuando una entidad puede sostener esa disciplina, sus servicios digitales dejan de depender de correcciones reactivas y empiezan a responder con mayor claridad a la diversidad real de las personas que los necesitan.
WCAG 2.1 y 2.2: qué cambia
WCAG 2.1 (2018) añadió criterios para dispositivos móviles, baja visión y discapacidad cognitiva. WCAG 2.2 (2023) suma criterios sobre foco visible, tamaño mínimo de los objetivos táctiles y autenticación accesible. Las versiones son compatibles hacia atrás: un sitio que cumple 2.2 también cumple 2.1. Para una entidad, lo importante no es la versión citada, sino que plantillas, componentes, documentos y formularios se revisen de forma continua.
Cómo lo aplica Coresis
En Postdata (CRC, 2025) aseguramos una navegación semántica completa y una interfaz con buen nivel de usabilidad, accesibilidad y lenguaje claro, según las disposiciones de Gobierno Digital. En la USPEC, los estándares GOV.CO sirvieron para validar decisiones de accesibilidad, navegación y contenido junto con los gestores de la entidad. Cuando la accesibilidad exige cambiar plantillas de una plataforma heredada, suele ser el momento de planear una migración a Drupal 11.
Lecturas relacionadas
- Ley 1712 de 2014: qué exige al portal de una entidad
- Arquitectura de información: qué es y cómo aplicarla
- Datos abiertos en Colombia: un portal que se use