Alcance y limitaciones

Las pruebas automáticas cubren mucho terreno de forma rápida y repetible. Saber exactamente dónde termina esa cobertura es lo que hace que los resultados sean accionables, así que esta página describe los límites de lo que el Detector mide hoy: primero los que afectan a todo el producto y después los específicos de cada checkpoint.

Dos principios recorren toda la lista:

• Precisión ante todo. El Detector está afinado para que un problema reportado sea un problema real. Cuando algo no se puede medir con confianza —un control que no se puede localizar, un color que no se puede resolver— se deja fuera del informe en lugar de aproximarlo.
• Automatización y revisión. Un escaneo es una primera pasada rápida y consistente sobre toda la página. Las áreas que siguen son aquellas en las que una revisión manual aporta más, y hacia donde estamos ampliando la cobertura.

---

En todo el producto

Sitios que bloquean el acceso automatizado

Algunos sitios usan protecciones WAF o antibot (Cloudflare, DataDome, Akamai, Imperva, PerimeterX, Vercel y otras) que rechazan cualquier navegador automatizado a nivel de red, de modo que la página nunca llega a cargar. La mayoría de esos bloqueos responden a la reputación de la IP de salida compartida y no a nada propio del navegador. En rondas recientes de sitios de viajes, aproximadamente 1 de cada 4 estaba protegido así.

Cuando ocurre, el escaneo lo dice: el resultado vuelve como un error explícito con el proveedor, el estado HTTP y una captura de la página de bloqueo, de modo que un sitio protegido nunca se confunde con uno limpio. (Esto aplica al motor asíncrono actual; la ruta síncrona heredada está en proceso de retirada.)

Un overlay flotante que se monta sobre un control a mitad del scroll también puede capturarse en lugar del propio control.

La página tal como se escanea

• La página se evalúa tal como está cuando se ejecuta el escaneo. El contenido que aparece después, o un cambio de pantalla en una aplicación de página única, no se vuelve a evaluar.
• Se mide lo que está en pantalla en ese momento. Los controles dentro de acordeones cerrados, pestañas, menús o modales sin abrir sí los alcanzan los tests de flujos de reserva, que abren cada panel como lo haría un visitante, pero no las comprobaciones generales de página completa.
• El contenido que solo aparece tras hacer scroll o varias interacciones queda fuera de la revisión general por el mismo motivo.

Color y fondo

• Modo claro. El contraste se mide sobre el tema claro.
• Los degradados y las imágenes de fondo sí se analizan: cuando no hay un valor de fondo único con el que comparar, el Detector recurre al análisis visual del elemento renderizado. Donde eso se vuelve una aproximación es en las composiciones de varias capas: overlays, background-blend-mode, filtros y background-attachment: fixed producen un color final construido a partir de capas superpuestas, así que el valor reportado es una lectura cercana y no exacta.
• La translucidez se resuelve componiendo el color sobre lo que hay detrás. Cuando el fondo no se puede establecer, se asume un fondo blanco: acertado en una página clara, menos en una oscura.
• Las notaciones de color que el motor todavía no interpreta (la sintaxis moderna de mezcla de color, por ejemplo) se omiten en lugar de aproximarse.
• Contexto CSS. Un hallazgo de contraste indica los colores y el ratio, no las declaraciones concretas —selectores, propiedades, valores— que hay detrás.

A cargo del navegador y del sistema operativo

Son exenciones deliberadas, no carencias del análisis:

• Los anillos de foco nativos. El navegador los adapta al pintar y están exentos de los requisitos de contraste de autor, así que se consideran visibles.
• Los desplegables del sistema. Windows, macOS y Android los pintan con su propio tema, así que los colores escritos en la página no son los que ve el usuario, y un desarrollador no podría cambiarlos.
• Los controles dejados por completo con los estilos por defecto del navegador —un checkbox o un campo de texto sin estilar— no se comprueban, porque su apariencia la decide el navegador.

Efectos visuales fuera del elemento medido

• Estilos de foco dibujados sobre un elemento hijo o un pseudoelemento. Cuando el efecto de foco vive en una "state layer" interna (el patrón habitual de Material Design) o en ::before / ::after, las comprobaciones de foco miden el control en sí y no llegan hasta ahí. El contraste de texto no se ve afectado: ese análisis sí resuelve el contenido de pseudoelementos y de shadow DOM.
• Señales de foco animadas. La página se congela antes de medir para que las transiciones no emborronen la comparación, de modo que un ripple o un efecto expansivo no se captura.
• El texto renderizado dentro de imágenes o SVG se lee como gráfico, no como texto.

Teclado

• Tab y Shift + Tab gobiernan la navegación de foco. Las flechas (↑ ↓ ← →), Home / End y Page Up / Page Down no forman parte del recorrido hoy.
• Los widgets personalizados —comboboxes, menús desplegables, interruptores, selectores de fecha— están cubiertos dentro de los flujos de reserva, donde los tests abren y recorren cada panel. Las comprobaciones generales de página completa todavía no los cubren.
• La activación por teclado se comprueba en los controles definidos en Generic Activation Command; la cobertura de elementos que no son interactivos de forma nativa se está definiendo.

Escala y consistencia

• Las listas largas se muestrean. Pasado un número determinado de controles del mismo tipo, y con un presupuesto de tiempo por elemento y por ejecución, las comprobaciones dejan de sondear más de lo mismo, de forma que un panel que no responde no puede bloquear el escaneo.
• Los pasos asistidos por IA se usan en varias comprobaciones. Los hallazgos en sí son estables; la redacción de una explicación y el detalle de una solución sugerida se generan en cada ejecución y varían ligeramente.
• Los sitios que se reconstruyen entre visitas, o en los que aparecen pop-ups y banners de consentimiento a mitad del escaneo, pueden dar resultados algo distintos de una ejecución a otra.
• Los controles repetidos se agrupan, de modo que un problema que afecta a una fila de botones idénticos se reporta una vez, con sus ocurrencias listadas, en lugar de como muchos hallazgos separados.

---

Por checkpoint

1.1.1 — Contenido no textual

⚠️ Actualmente no está en producción. Los modelos de clasificación de imágenes en los que se apoyaba este checkpoint fueron discontinuados. Su integración está prevista para una próxima versión.

• La clasificación sigue al nombre accesible: una imagen sin él se trata como decorativa, porque no hay texto alternativo que evaluar. Ver Clasificación de imágenes.

1.3.1 — Información y relaciones

• Los nombres de región se comprueban por presencia, no por calidad. Dos navegaciones llamadas "nav 1" y "nav 2" cumplen la regla, aunque digan poco al usuario.
• De la región main se comprueba que exista, no si el contenido que hay dentro es realmente el contenido principal de la página.
• De los encabezados se comprueba el anidamiento. Que los niveles sigan además un orden razonable es una cuestión aparte y, como se lee la página renderizada y no el código fuente, el anidamiento que el navegador repara por su cuenta se reporta tal como lo experimenta el usuario.
• Los encabezados visuales se identifican por su apariencia, lo que implica un juicio: un encabezado con un estilo muy sutil puede no detectarse, y una cita destacada o un precio con estilo llamativo puede detectarse.
• Navegadores y lectores de pantalla varían en cómo exponen y anuncian las regiones, así que una página puede comportarse de forma algo distinta a lo que sugiere el informe.

1.4.1 — Uso del color

• Los enlaces se evalúan cuando están dentro de un texto circundante y se distinguen solo por color; los enlaces diferenciados por otros estilos quedan fuera de esta comprobación por diseño. Ver Texto circundante.
• Los estados de foco basados solo en color se detectan cuando cambia un color sólido en el propio control: fondo, borde, contorno, texto o icono, incluidos los colores translúcidos. El estilo de foco que vive en otro sitio queda fuera del alcance actual: indicadores dibujados en un elemento hijo o en un pseudoelemento, ripples y animaciones, degradados, la mayoría de usos de opacidad, y los casos en que cambian dos propiedades de color a la vez. Color solo en estado focus documenta cada patrón, con una guía rápida para revisores.

1.4.3 — Contraste (mínimo)

• Los fondos con degradado e imagen sí se evalúan mediante análisis visual del elemento renderizado, igual que los elementos cuyo contenido está dentro de shadow DOM o lo genera ::before / ::after.

• Los fondos con muchas capas —imagen más overlay más modo de mezcla o filtro, o un fondo fijado al viewport— dan una lectura aproximada en lugar de un valor exacto, porque el color final lo compone el navegador al pintar.

• Texto con degradado. Cuando se usa un degradado como color del texto (background-clip: text), no hay un valor de primer plano único que medir.

• Hover y focus se evalúan sobre el elemento que lleva el estilo; cuando el elemento que reacciona al evento es el padre del texto analizado, esa correspondencia todavía no se resuelve.

  Ejemplos comentados en Límites de gradiente.

1.4.4 — Cambio de tamaño de texto

• Cobertura por ejecución. Las páginas largas se procesan en iteraciones con un presupuesto de pasos; las páginas con secciones sticky consumen más de ese presupuesto, así que una página muy larga puede revisarse de forma menos exhaustiva que una corta.
• Precisión de la interacción. Abrir menús y paneles depende de que el agente localice el control; se llama a un segundo modelo, más capaz, para resolver los clics dudosos. Los menús hamburguesa han producido falsos positivos aislados.
• Los estilos computados sobrescritos —un tamaño declarado en vh y reescrito después en rem— pueden leerse como un fallo de escalado. Ver Escalado de texto.
• Re-renderizado de frameworks. Los componentes estilo React y Next que reasignan rol, nombre o contenido de texto al re-renderizar son una fuente conocida de falsos positivos.

1.4.10 — Reflow

• El análisis de visión gobierna la comprobación, así que los casos límite pueden caer de cualquier lado.
• El contenido que cambia rápido puede no capturarse mientras se asienta.
• Se evalúan los elementos visibles; el contenido oculto o fuera del viewport no.
• Las transparencias y los efectos visuales complejos afectan a la detección de solapamientos.
• Las barras de scroll no se ven en la captura que devuelve la extensión.

1.4.11 — Contraste no textual

• Estado hover. Las imágenes de fondo, los degradados, los efectos en pseudoelementos, las transiciones CSS lentas y el hover disparado por JavaScript reducen la precisión. Los componentes deshabilitados, el contraste de texto, el contraste en foco, los estados activo y visitado y los colores de hover por defecto del navegador se tratan en otro sitio o están exentos. Ver Contraste al pasar el cursor.
• Los indicadores de foco sobre un fondo no uniforme se comparan con el par de colores de mayor contraste, lo que mantiene la comprobación libre de falsas alarmas; un indicador que falla solo contra una parte de su fondo puede pasar.
• Radios y checkboxes. Los controles que el sitio no ha estilado se dejan al navegador; los campos que ya muestran un placeholder, un valor o una opción seleccionada se consideran identificables por su texto. El reconocimiento se apoya en que el control tenga un borde visible, y la comprobación resuelve los casos límite a favor de aprobar.
• Controles solo con icono. Entran en alcance los botones, enlaces y pestañas cuyo contenido es íntegramente un icono. Un control que además lleva texto visible se identifica por ese texto, y las fotos, los logos y los enlaces formados solo por una imagen se cubren en 1.1.1 y no aquí.
• Elementos gráficos. Los elementos que no se pueden asociar con una parte concreta de la página renderizada se dejan fuera del análisis en lugar de reportarse de forma aproximada.

2.1.1 — Teclado

Algunos elementos se omiten por diseño, para no disparar acciones no deseadas durante un escaneo: enlaces simples, campos de formulario, botones de envío, pestañas ya seleccionadas, elementos ocultos visualmente y elementos sin interacción de teclado estándar. Ver Implementación operable por teclado.

2.1.2 — Sin trampa de teclado

• La navegación con flechas y los cambios de contexto inesperados al enfocar se cubren en comprobaciones aparte, no en esta.

2.4.3 — Orden de foco

• Los elementos colapsados se omiten en el estado normal, porque al quitar los estilos aparecerían justo después de su disparador y falsearían el orden.
• Los elementos deshabilitados e invisibles se excluyen, igual que los skip links que mueven el foco a <main>, que es justamente para lo que existen.

2.4.7 — Foco visible

• Presencia, no intensidad. Esta comprobación confirma que existe un indicador de foco visible; cuánto destaca se mide en 1.4.11.
• Se examinan los elementos alcanzables con Tab.
• Los indicadores muy sutiles están en el límite de lo que la comparación de imágenes puede separar del ruido de renderizado; el umbral actual está puesto para mantener la comprobación libre de falsas alarmas.
• Las páginas de Mastercard se tratan con una captura directa en lugar del proceso habitual de clonado de estilos.

4.1.2 — Nombre, rol, valor

• El nombre y el rol se leen del árbol de accesibilidad del navegador, así que el resultado refleja lo que realmente anuncia un lector de pantalla, incluido el contenido dentro de shadow DOM e iframes.
• El estado deshabilitado se lee del atributo disabled, de modo que un control que solo parece deshabilitado por estilos se juzga por lo que de verdad anuncia.

4.1.3 — Mensajes de estado

• Los spinners decorativos de carruseles y galerías con carga diferida se reportan hoy junto a los reales; afinar esa distinción está en curso.
• Dónde apareció un mensaje se deduce de la estructura de la página y no de la posición en pantalla. Eso coincide con el resultado visual en la mayoría de las páginas; el caso que se está afinando es el de un toast colocado lejos de su disparador dentro de la estructura.

TabIndex

• El análisis cubre los elementos presentes en la página activa, con un análisis más semántico y contextual previsto.
• Cuando la intención detrás de un valor de tabindex no se puede establecer automáticamente, se pide al auditor que la confirme en lugar de que la herramienta la suponga.

Hospitality Booking

Los tests de flujos de reserva abren cada widget y auditan dentro de él, lo que trae su propio alcance. En resumen:

• Dentro de los paneles abiertos. El texto de la página circundante lo cubre la comprobación de contraste de página completa, de modo que ambas no reportan por duplicado. Contraste de color
• Los controles se identifican por su apariencia y comportamiento en lugar de haciendo clic en ellos, lo que seleccionaría un destino o dispararía una búsqueda a mitad de la comprobación. Un control que no da ninguna señal externa de serlo puede, por tanto, pasar desapercibido. Navegación por teclado
• Los hallazgos de operabilidad se mantienen separados de los de navegación: los controles inalcanzables, los campos de texto donde se puede escribir, los enlaces ordinarios, los botones de envío y los desplegables del sistema se reportan bajo sus propias reglas, no como fallos de operabilidad. Operabilidad por teclado
• Se reporta trampa cuando el foco se queda atrapado en un único control. Un bucle entre varios controles se trata por separado y, cuando una página cambia a mitad del test, la comprobación calla en lugar de reportar algo que no ha podido confirmar. Trampas de teclado dentro de paneles
• Los widgets construidos de forma inusual se reportan como "no se abrió", de modo que queda claro que su contenido no se midió.