Llevo varios años trabajando en portales institucionales y hay algo que me sigue sorprendiendo: los mismos errores de accesibilidad aparecen una y otra vez. No importa si es una entidad grande o pequeña, si tienen presupuesto o no, si usan WordPress o están en Drupal. Los problemas se repiten como un loop infinito.
Y lo más bacano es que muchos de estos errores son fáciles de evitar. No requieren conocimientos avanzados ni herramientas costosas. Solo necesitan que alguien se detenga cinco minutos a pensar en cómo otras personas van a usar ese sitio.
El drama de las imágenes sin texto alternativo
Este es el campeón indiscutible de los errores. Trabajo tras trabajo, encuentro imágenes sin atributo alt o, peor aún, con textos como "imagen1.jpg" o "banner_principal_final_v2.png". Cuando trabajé en la renovación del portal de FONTUR, una de las primeras tareas fue hacer una auditoría de las imágenes existentes. De más de 300 imágenes en el sitio anterior, menos del 20% tenía un texto alternativo útil.
El problema no es solo técnico. Es que nadie piensa en la persona que usa un lector de pantalla. Para ellos, esa imagen informativa que explica un trámite simplemente no existe. Es como si les hubiéramos puesto una pared invisible en medio del contenido.
Y hay matices que muchos no consideran. Una imagen decorativa debería tener alt="" (vacío, pero el atributo debe existir). Una imagen con información relevante necesita una descripción clara. Un logo puede llevar el nombre de la entidad. Pero en la práctica, veo que o se llenan todos los alt con textos innecesarios o se dejan todos vacíos. No hay término medio.
Formularios que parecen acertijos
Los formularios son otro campo minado. Labels que no están asociados correctamente con sus inputs, placeholders usados como etiquetas, mensajes de error que no se anuncian, campos obligatorios sin indicación clara. La lista es larga.
Recuerdo un caso específico en la Secretaría Jurídica Distrital. Tenían un formulario de consulta de conceptos jurídicos que era perfectamente funcional visualmente, pero un desastre para tecnologías de asistencia. Los campos no tenían labels explícitos, solo placeholders. Cuando hacías clic en un campo, el placeholder desaparecía y ya no sabías qué debías escribir ahí.
La solución fue simple: agregar labels visibles, asociarlos correctamente con for e id, incluir aria-required="true" en campos obligatorios y asegurarnos de que los mensajes de error se anunciaran con aria-live. Nada del otro mundo, pero hizo una diferencia enorme.
Lo que me genera dudas es por qué esto no viene por defecto en más CMSs o frameworks. Laravel, por ejemplo, tiene helpers para formularios, pero no fuerza buenas prácticas de accesibilidad. Podrías argumentar que es responsabilidad del desarrollador, y tenés razón, pero ¿no deberíamos hacer que lo correcto sea también lo más fácil?
Contraste de colores y tamaños de fuente
Este error es particularmente frustrante porque es visible para todos, no solo para usuarios con discapacidad. Textos grises claros sobre fondos blancos, botones con colores pasteles, menús con letras diminutas. Lo veo constantemente.
Las WCAG establecen ratios de contraste específicos: 4.5:1 para texto normal, 3:1 para texto grande. Hay herramientas gratuitas como el Colour Contrast Analyser que te dicen en segundos si tu combinación de colores cumple. Pero aún así, los diseñadores entregan mockups con contrastes insuficientes y los desarrolladores los implementamos sin cuestionar.
También está el tema de los tamaños de fuente en unidades fijas. Todavía encuentro sitios con fuentes en píxeles que no escalan cuando el usuario aumenta el tamaño del texto en su navegador. Usar rem o em soluciona esto de una, pero requiere cambiar la mentalidad de diseño.
Navegación por teclado olvidada
Muchos desarrolladores solo prueban sus sitios con mouse. Nunca presionan Tab para ver si pueden navegar, nunca verifican si los menús desplegables funcionan con Enter o las flechas del teclado.
En un portal institucional, esto es especialmente problemático en componentes como acordeones, tabs, modales y menús complejos. He visto menús de navegación hermosos que simplemente no se pueden abrir sin mouse. O peor, que atrapan el foco del teclado y no te dejan salir.
La accesibilidad no es una funcionalidad extra que agregas al final. Es parte de hacer bien tu trabajo. Y en instituciones públicas, donde el servicio debe ser para todos sin excepción, debería ser una prioridad desde el día uno. Pero entre presupuestos ajustados, cronogramas imposibles y falta de capacitación, termina siendo lo primero que se sacrifica.
¿Cómo cambiamos esto? No tengo una respuesta definitiva, pero creo que empieza por hacer visible el problema y compartir soluciones prácticas que cualquier equipo pueda implementar.