ACCESIBILIDAD ≠ OVERLAY · 35
La accesibilidad no se demuestra con una puntuación: se demuestra con personas que pueden utilizar tu web
📅 6 de noviembre de 2026 · ⏱ 7 min de lectura
Un 100 % automático puede convivir con barreras reales. La prueba decisiva es que las personas puedan completar sus tareas.
01. Qué significa realmente una puntuación de accesibilidad
Una puntuación es el resultado de un conjunto concreto de comprobaciones, ejecutadas en unas condiciones determinadas. No representa a todas las personas ni a todas las situaciones de uso. Una web puede obtener una cifra excelente en la página de inicio y tener problemas graves en el proceso de compra, en una reserva o en el área privada. La accesibilidad se evalúa mejor preguntando qué tareas puede realizar una persona, con qué herramientas y sin qué barreras.
Conviene distinguir entre la calidad de una medición y la calidad de la experiencia. Una herramienta puede medir correctamente lo que está programada para medir y, aun así, dejar fuera aspectos esenciales. El porcentaje no es inútil: sirve para detectar regresiones y orientar mejoras. El error aparece cuando se convierte en una garantía universal o en un argumento publicitario que sustituye las pruebas reales.
02. Qué pueden detectar las herramientas automáticas
Los analizadores automáticos identifican errores verificables: imágenes sin alternativa textual, ciertos problemas de contraste, campos sin etiquetas, relaciones semánticas incorrectas o atributos que incumplen reglas técnicas. Son especialmente útiles para revisar muchas páginas, repetir pruebas tras una actualización y descubrir patrones que afectan a componentes compartidos.
Sin embargo, su cobertura es parcial. No basta con ejecutar un escáner una sola vez ni con limitarse a la portada. Deben revisarse distintas plantillas, estados interactivos, mensajes de error y recorridos. Los resultados necesitan interpretación: una advertencia puede requerir una decisión editorial, y la ausencia de alertas no demuestra que el contenido resulte comprensible.
03. Lo que las herramientas no pueden comprender
Un programa no puede decidir de forma fiable si el texto alternativo de una imagen transmite su función real, si una instrucción resulta clara para quien no ve la pantalla o si el orden de lectura ayuda a comprender una operación compleja. Tampoco puede representar todas las combinaciones de navegador, dispositivo y tecnología de apoyo.
Pensemos en un enlace llamado «pulsa aquí». Puede ser técnicamente un enlace válido y seguir siendo ambiguo cuando una persona escucha una lista de enlaces con su lector de pantalla. Una validación automática puede no comprender el contexto completo. La solución exige revisar el propósito de la interacción y escribir un nombre que permita anticipar el destino.
04. Una web con un 100 % que sigue siendo inaccesible
Imaginemos una tienda que muestra un 100 % en un informe automatizado. Sus botones tienen nombre y sus imágenes incluyen texto alternativo. Sin embargo, al abrir el carrito aparece un diálogo que no recibe el foco del teclado; al cerrarlo, el foco se pierde. El cliente no consigue terminar el pedido. El porcentaje no describe esa barrera.
También puede ocurrir que un formulario muestre el error solo en rojo, que un selector dependa de arrastrar con el ratón o que la confirmación desaparezca antes de poder leerla. La página puede parecer perfecta en una captura. Para la persona afectada, el servicio sigue siendo inaccesible. Por eso hay que probar tareas, no únicamente páginas estáticas.
05. La navegación por teclado como prueba básica
Una comprobación sencilla consiste en apartar el ratón. Usa Tab y Mayús+Tab para recorrer enlaces, botones y campos; activa controles con Intro o Espacio cuando corresponda; comprueba que el foco es visible y sigue una secuencia lógica. Prueba menús desplegables, modales y componentes que se actualizan dinámicamente.
No basta con poder llegar a un elemento: también hay que poder utilizarlo, cerrarlo y continuar. Si el foco queda atrapado sin salida, salta a una zona inesperada o desaparece tras una acción, la experiencia puede bloquearse. Documenta el recorrido exacto y repite la prueba después de corregir el problema.
06. Lectores de pantalla: más allá de las etiquetas
Los lectores de pantalla permiten comprobar cómo se anuncian los encabezados, enlaces, formularios, estados y cambios dinámicos. Un encabezado que solo parece grande visualmente no sustituye a un encabezado semántico. Un icono sin nombre puede convertirse en un control incomprensible. La estructura de la página debe ayudar a orientarse sin depender de la vista.
La prueba debe incluir la comprensión de los mensajes. ¿Se anuncia que un formulario tiene errores? ¿Se identifica el campo concreto? ¿Se comunica que se ha añadido un producto al carrito? ¿Es posible volver a la navegación principal? Estas preguntas revelan problemas que un número global no puede resumir.
07. Formularios, errores y procesos completos
Los formularios concentran muchas barreras: etiquetas ausentes, instrucciones tardías, validaciones confusas y errores que no se anuncian. Un proceso accesible explica los datos necesarios antes de pedirlos, identifica claramente los campos obligatorios y ofrece oportunidades reales para corregir los fallos.
La evaluación debe abarcar el recorrido completo, desde la entrada hasta la confirmación. En una cita médica, por ejemplo, no sirve que la página informativa sea accesible si el calendario no se puede manejar con teclado. En una compra, el objetivo no es abrir el carrito: es finalizar el pedido con autonomía.
08. Diseño visual, zoom y comprensión
El contraste, el tamaño de los objetivos interactivos, el espaciado y la adaptación a pantallas pequeñas influyen en la accesibilidad. Prueba el sitio con ampliación elevada y verifica que el contenido no desaparece ni obliga a desplazamientos innecesarios en dos direcciones. El foco visible y los estados de error deben distinguirse sin depender solo del color.
La comprensión también forma parte de la experiencia. Textos claros, títulos informativos, botones con nombres concretos y una navegación consistente reducen errores. Una interfaz que cambia de comportamiento sin avisar puede resultar difícil incluso cuando todos sus elementos superan una revisión técnica aislada.
09. Las WCAG 2.2 como referencia, no como trofeo
Las WCAG 2.2 ofrecen criterios verificables para trabajar con rigor. Ayudan a definir requisitos, documentar incumplimientos y comprobar mejoras. Pero conformidad y puntuación automática no son sinónimos. No existe una única cifra capaz de demostrar por sí sola que se satisfacen todos los criterios aplicables.
Utiliza los criterios como base de una metodología que combine revisión del código, comprobaciones manuales, pruebas funcionales y participación de usuarios. Una declaración de accesibilidad responsable debe reflejar el estado real del servicio y sus limitaciones conocidas, no prometer resultados que no se han comprobado.
10. Pruebas con personas y tecnologías de apoyo
Las pruebas con personas con discapacidad aportan información sobre estrategias, dificultades y expectativas que los equipos pueden pasar por alto. Es importante observar tareas reales y escuchar los resultados sin convertir a una persona en representante de todas las discapacidades. Diferentes perfiles y tecnologías revelan barreras diferentes.
Define escenarios: localizar información, completar una inscripción, cambiar una preferencia o descargar un documento. Anota qué ocurre, dónde se produce el bloqueo y cómo afecta al objetivo. Prioriza los problemas que impiden terminar tareas esenciales y verifica las soluciones con nuevas pruebas.
11. Por qué un overlay no resuelve el problema
Un overlay puede ofrecer controles superficiales de presentación, pero no reemplaza una estructura semántica correcta, un formulario bien construido o una interacción que funcione con teclado y lector de pantalla. Tampoco puede decidir si los contenidos explican adecuadamente un trámite o si una experiencia completa es comprensible.
Instalar una capa de accesibilidad no convierte automáticamente un sitio en conforme con las WCAG 2.2. En ocasiones añade nuevas interfaces que también deben evaluarse. La solución duradera consiste en corregir el producto original, asignar responsabilidades y mantener los cambios a lo largo del tiempo.
12. Cómo construir un proceso de mejora continua
Empieza por identificar los recorridos más importantes del sitio y las plantillas que utilizan. Combina herramientas automáticas con una revisión manual de teclado, foco, estructura, formularios, ampliación y lectores de pantalla. Registra incidencias con pasos reproducibles, impacto y responsable de corrección.
Después, incorpora comprobaciones a cada publicación y actualización. Revisa los componentes compartidos, forma a quienes redactan contenidos y vuelve a probar las tareas críticas. El objetivo no es alcanzar un número para mostrar en una captura: es que más personas puedan utilizar el servicio de forma autónoma, segura y previsible.