ACCESIBILIDAD ≠ OVERLAY · 32
Accesibilidad ≠ Overlay: la accesibilidad también se planifica
📅 2 de noviembre de 2026
Planificar la accesibilidad desde el inicio evita barreras, retrabajos y decisiones improvisadas. Un proyecto web inclusivo necesita requisitos, responsables, diseño, desarrollo, pruebas y mantenimiento.
1. La accesibilidad es una decisión de proyecto
Cuando se habla de accesibilidad únicamente al final del desarrollo, los problemas suelen estar integrados en la arquitectura, el diseño y las interacciones. Entonces corregirlos cuesta más y puede exigir rehacer componentes enteros. Planificar significa incorporarla a las decisiones que se toman desde el primer día.
No se trata de añadir una tarea decorativa a la lista de pendientes. Se trata de definir cómo navegará una persona sin ratón, cómo comprenderá un formulario con un lector de pantalla y qué ocurrirá cuando necesite ampliar el texto. Esas preguntas deben orientar el proyecto antes de elegir una plantilla o construir una página.
Un overlay no puede sustituir estas decisiones. Si la estructura y las funciones presentan barreras, una capa superpuesta no garantiza que desaparezcan.
2. Definir objetivos y criterios verificables
Un requisito como «la web será accesible» es demasiado impreciso. El equipo necesita objetivos comprobables: navegación completa mediante teclado, foco visible, formularios etiquetados, mensajes de error comprensibles y contenido adaptable a distintas pantallas.
Las WCAG 2.2 proporcionan una referencia técnica útil para convertir intenciones en criterios de aceptación. Cada funcionalidad importante debería tener condiciones claras para considerarse terminada. Por ejemplo, un menú no está completo si solo funciona con el ratón.
También conviene determinar el nivel de conformidad objetivo, el alcance de las páginas y procesos, y las responsabilidades de validación. La planificación evita que cada profesional interprete la accesibilidad de manera diferente.
3. Conocer a las personas y sus tareas reales
La accesibilidad no se limita a una lista de errores técnicos. Una persona puede necesitar localizar información, solicitar una cita, comprar un producto o completar un trámite. El éxito se mide por su capacidad para realizar esas tareas de forma autónoma.
Investigar necesidades de personas con distintas discapacidades ayuda a descubrir obstáculos que un equipo puede pasar por alto. Es importante contemplar el uso de lectores de pantalla, navegación por teclado, ampliación, control por voz y otras formas de interacción.
No basta con imaginar usuarios ideales. Los recorridos reales, los contenidos complejos y los mensajes de error deben formar parte de las decisiones iniciales. Cuando sea posible, incluye personas con discapacidad en las pruebas y en la evaluación de prototipos.
4. Diseñar una estructura comprensible
Antes de programar, define una jerarquía de encabezados coherente, navegación predecible, enlaces descriptivos y formularios con instrucciones visibles. Los componentes deben mantener el mismo comportamiento en todas las secciones.
Los contrastes, los estados de foco, el tamaño de los controles y la adaptación a pantallas pequeñas también se diseñan. Si solo se revisan cuando la web está terminada, pueden entrar en conflicto con decisiones visuales ya aprobadas.
Un sistema de diseño con componentes accesibles y documentados facilita que las páginas nuevas mantengan la calidad. No significa que nunca haya errores, pero reduce la repetición de problemas y simplifica su corrección.
5. Desarrollar con semántica y comportamiento correctos
En desarrollo, el HTML semántico debe ser la primera opción. Un botón real, una etiqueta asociada a su campo y una estructura lógica ofrecen información que las tecnologías de apoyo pueden interpretar. Imitar estos elementos con contenedores genéricos suele añadir complejidad innecesaria.
Los componentes dinámicos requieren atención especial: ventanas de diálogo, pestañas, menús desplegables y mensajes que aparecen sin recargar la página. Deben funcionar con teclado y comunicar sus cambios de estado de forma comprensible.
Si utilizas WordPress, Divi o plugins, prueba el resultado real. Que una herramienta anuncie compatibilidad con accesibilidad no demuestra que cada combinación de módulos, estilos y contenidos funcione correctamente.
6. Incluir pruebas en cada fase
Las pruebas deben comenzar con prototipos y continuar durante el desarrollo. Revisar temprano un menú o formulario evita repetir el mismo defecto en decenas de páginas. Las pruebas automáticas ayudan, pero no cubren toda la experiencia.
Una revisión práctica combina teclado, lector de pantalla, zoom, pantallas pequeñas y comprobación de mensajes de error. Conviene probar tareas completas, no únicamente componentes aislados: desde encontrar un producto hasta finalizar una compra.
Documenta los problemas con pasos para reproducirlos, impacto, prioridad y persona responsable. Después de cada corrección, vuelve a comprobar la tarea. Una incidencia no se cierra solo porque alguien haya cambiado el código.
7. Asignar presupuesto, tiempo y responsables
La accesibilidad necesita recursos reales. Si no tiene tiempo reservado, suele quedar desplazada por otras urgencias. Incluye formación, revisión de diseños, pruebas y correcciones en la estimación inicial del proyecto.
Define quién valida los componentes, quién revisa los textos, quién comprueba los formularios y quién decide si una versión puede publicarse. La responsabilidad compartida no debe convertirse en ausencia de responsables concretos.
Una planificación razonable también contempla dependencias externas, como pasarelas de pago, servicios de reservas o widgets de terceros. Si una pieza crítica introduce barreras, es necesario detectarlo antes de comprometer toda la experiencia.
8. Planificar también el mantenimiento
La publicación no marca el final de la accesibilidad. Las actualizaciones de temas, plugins y contenidos pueden introducir regresiones. Por eso, el plan debe incluir revisiones después de cambios relevantes y controles periódicos de los recorridos críticos.
Establece un procedimiento para recibir incidencias de accesibilidad y responder a ellas. Registrar fecha, descripción, prioridad, corrección y resultado de la nueva prueba permite mejorar el servicio de forma continua.
La accesibilidad sostenible forma parte del ciclo completo: planificación, diseño, desarrollo, pruebas, lanzamiento y mantenimiento. No se compra con un botón flotante ni se resuelve en una única auditoría.
9. Un ejemplo práctico: una web de reservas
Imagina que una empresa encarga una web para reservar servicios. En la planificación se identifican las tareas principales: elegir servicio, fecha, horario, introducir datos y confirmar la reserva. Cada paso debe poder completarse con teclado y tecnologías de apoyo.
Durante el diseño se prevén etiquetas claras, mensajes de disponibilidad y errores comprensibles. En desarrollo se implementan controles semánticos y una gestión correcta del foco. En pruebas se simula el recorrido completo, incluyendo errores y cambios de horario.
Si se espera hasta el final para revisar la accesibilidad, el calendario de reservas puede requerir una reconstrucción. Planificarla desde el principio reduce ese riesgo y mejora la experiencia para todas las personas.
10. Qué puedes hacer desde hoy
Antes de iniciar tu próximo proyecto, escribe tres tareas esenciales que las personas deberán completar. Para cada una, define cómo funcionará sin ratón, qué información recibirá un lector de pantalla y qué ocurrirá si se produce un error.
Incluye criterios WCAG 2.2 en la definición de terminado, reserva tiempo para pruebas manuales y asigna responsables. Revisa también las herramientas de terceros antes de integrarlas.
La pregunta no es qué overlay instalar cuando la web esté publicada. La pregunta es cómo construir una web que no necesite esconder sus barreras detrás de una capa.