ACCESIBILIDAD ≠ OVERLAY · 30
Accesibilidad ≠ Overlay: 10 comprobaciones para saber si tu web es realmente accesible
📅 29 de octubre de 2026 · ⏱ 5 min de lectura
La accesibilidad no se demuestra con un icono flotante. Se comprueba cuando una persona puede orientarse, comprender el contenido y completar una tarea sin obstáculos. Estas diez comprobaciones ayudan a pasar de la apariencia a la experiencia real.
01. Empieza por una tarea, no por el widget
Elige un objetivo importante para tus visitantes: pedir presupuesto, reservar una cita, comprar un producto o encontrar un teléfono. Una auditoría útil comienza con esa tarea completa, no con la comprobación de que existe un botón de accesibilidad.
Anota cada paso y pregunta si puede terminarse sin depender de una forma concreta de ver, oír o manejar el dispositivo. Una página puede superar controles superficiales y seguir impidiendo que alguien contacte con tu empresa.
02. Comprueba el recorrido con teclado
Aparta el ratón y recorre la página con Tab y Shift+Tab. Usa Enter y, cuando corresponda, Espacio para activar botones. Comprueba que puedes abrir y cerrar menús, elegir opciones y llegar al final del proceso.
Si algún control solo responde al clic o el orden de navegación salta de forma inesperada, has encontrado una barrera funcional. Ningún cambio de contraste del overlay sustituye la corrección de ese componente.
03. Observa el foco y los diálogos
El indicador de foco debe ser visible y no quedar oculto bajo cabeceras fijas. Cuando aparece un cuadro de diálogo, el foco debe trasladarse de forma coherente, permanecer donde corresponde y volver al lugar adecuado al cerrarlo.
Piensa en una confirmación de compra: si el teclado sigue recorriendo enlaces detrás de la ventana, la persona no puede interactuar de forma fiable. Hay que reparar el comportamiento del diálogo, no añadir otro panel flotante.
04. Escucha la página con un lector de pantalla
Utiliza un lector de pantalla para recorrer títulos, enlaces, botones y campos. Escucha si cada control anuncia su propósito y si la secuencia de lectura mantiene el sentido. Una imagen informativa necesita una alternativa que transmita su contenido.
No basta con que el texto se vea correctamente. La estructura semántica debe comunicar a las tecnologías de apoyo qué es un encabezado, qué es una etiqueta y cuándo ha cambiado el estado de un control.
05. Revisa formularios y errores
Intenta enviar un formulario vacío y después introduce un dato incorrecto. ¿Se explica qué campo falla y cómo solucionarlo? ¿La etiqueta permanece disponible cuando escribes? ¿Se identifica claramente qué información es obligatoria?
Un mensaje que solo dice «Error» o que depende exclusivamente del color deja a muchas personas sin instrucciones. La solución es diseñar validaciones comprensibles, asociadas a sus campos y anunciadas cuando corresponda.
06. Amplía, adapta y usa el móvil
Aumenta el zoom del navegador hasta el 200 % y comprueba que no desaparezcan acciones esenciales. Prueba tamaños de pantalla reducidos, orientación vertical y horizontal y espaciado de texto cuando resulte pertinente.
El contenido debe adaptarse sin exigir desplazamientos imposibles ni superponer botones. Un widget puede ofrecer una fuente más grande, pero si el diseño se rompe al ampliarla, la barrera sigue ahí.
07. Comprueba contenido y estructura
Revisa que los encabezados describan la organización del contenido, que los enlaces tengan nombres útiles fuera de contexto y que las instrucciones sean claras. Evita utilizar una imagen de texto para transmitir información esencial.
Una estructura lógica ayuda tanto a quien utiliza lector de pantalla como a quien busca rápidamente una respuesta. La accesibilidad también depende de decisiones editoriales y de arquitectura de información.
08. Interpreta las pruebas automáticas
Las herramientas automáticas son valiosas para detectar problemas como determinadas ausencias de nombres, errores de marcado o contrastes insuficientes. Pero no pueden decidir por sí solas si un proceso resulta comprensible o si una interacción es usable.
Combina los resultados con revisión manual, teclado, tecnologías de apoyo y, cuando sea posible, pruebas con personas con discapacidad. Una puntuación automática no equivale a conformidad WCAG.
09. Prioriza los bloqueos y asigna responsables
Clasifica los hallazgos por impacto. Un bloqueo que impide pagar o enviar una solicitud suele requerir atención antes que un ajuste visual menor. Registra el problema, dónde ocurre, cómo reproducirlo y quién lo resolverá.
Convierte la auditoría en trabajo concreto para diseño, desarrollo y contenidos. Corregir la causa en la plantilla o el componente compartido suele aportar más valor que maquillar síntomas en una página aislada.
10. Repite las pruebas después de cada cambio
Cada actualización de WordPress, cambio de tema, módulo Divi, plugin o nuevo formulario puede introducir barreras. Incorpora una lista de comprobación de accesibilidad al proceso de publicación y mantenimiento.
Toma las WCAG 2.2 como referencia técnica y documenta las decisiones y las pruebas realizadas. La meta no es mostrar un símbolo de accesibilidad: es que las personas puedan utilizar tu web con autonomía.