Prueba de accesibilidad

Comprobaciones automáticas para una sola URL o ejecuciones por lotes en muchas páginas.

En el plan Free, el panel muestra la cobertura de pruebas sin el estado de lotes. Las redirecciones automáticas, las pruebas en segundo plano y la programación están disponibles desde Basic. Las secciones se llaman «Probar una página» y «Probar varias páginas».

La ocultación integrada incluye integraciones para Borlabs Cookie 2.x y 3.x; consulta las versiones probadas y las correcciones necesarias de EZZE en el apartado sobre versiones de banners. Solo se aplica a solicitudes de prueba con una clave válida; la configuración del banner para los visitantes habituales no cambia. Las capturas guardadas no se modifican: ejecuta una nueva prueba después de una corrección. Las fechas y horas siguen el formato de la vista correspondiente; el formato de hora procede de WordPress, en Ajustes → Generales (por ejemplo, H:i para el formato de 24 horas).

Antes de la primera prueba: activa las funciones en la nube

El Accessibility Test se ejecuta a través del servicio en la nube de EZZE. Mientras la conexión gratuita a la nube no esté activa, la página de la prueba muestra una tarjeta de activación completa en lugar de un formulario que permita iniciar la prueba. El título de la página y la Ayuda siguen disponibles; la hoja de Ayuda distingue entre el plan Free y los planes de pago y explica el alcance y los límites pertinentes, los tipos de prueba disponibles, la interpretación de los resultados, los problemas habituales al iniciar, el procesamiento en la nube y el cupo de URL. La navegación de pruebas y los ajustes solo aparecen después de la activación y tampoco pueden abrirse antes mediante un enlace directo de pestaña. Abrir la activación de Funciones Cloud abre el panel de Funciones Cloud en el Escritorio, donde inicias la activación gratuita de Freemius. No se necesita clave de licencia ni datos de pago. Durante la primera activación se ocultan la barra lateral y la lista de resultados vacía, para que la activación siga siendo el siguiente paso claro. Los resultados guardados siguen visibles. Si aún falta la confirmación por correo electrónico, puedes continuar la activación o reenviar el correo.

Qué hace

El Accessibility Test ejecuta un análisis de accesibilidad en el navegador (incluye reglas tipo axe) similar a las herramientas habituales de desarrollo. Los resultados se desglosan con gravedad e indicaciones de remediación.

Para qué sirve

• Automatización: Detecta un subconjunto de incidencias (a menudo se cita ~30–40 % de los fallos WCAG detectables por máquina)
• Seguimiento: Las repeticiones muestran tendencias
• Priorización: Pone primero los hallazgos frecuentes o graves
• Historial: La cronología documenta el esfuerzo
• QA de publicación: Ejecútalo antes o después de publicar

Límites

• Repeticiones por URL: Ilimitadas en todos los planes (la misma URL se puede volver a probar libremente)
• URLs distintas por mes:

Importante: cada URL normalizada cuenta una sola vez al mes respecto al límite, aunque la pruebes muchas veces. Escritorio y móvil generan resultados separados, pero no consumen una segunda URL para la misma dirección. Las diferencias limitadas al protocolo, mayúsculas del host, puertos predeterminados, barra final o parámetros de seguimiento no crean otra entrada; los parámetros de consulta con significado funcional siguen siendo distintos.

Banners de cookies, bots y captura del viewport

La captura del viewport está activada por defecto para los ajustes nuevos, también en Free. Puedes desactivarla en cualquier momento; una desactivación guardada se conserva durante las actualizaciones. Esto no sustituye la activación obligatoria de la nube ni inicia ninguna prueba automáticamente.

Si activas la captura opcional del viewport en los ajustes del Accessibility Test, el método de captura depende del plan. En Free, la vista previa compacta procede de la misma ejecución de PageSpeed que la puntuación y las comprobaciones; la ejecución completa además el trabajo de rendimiento necesario para la imagen y puede tardar un poco más. A partir de Basic, el plugin envía al proxy de EZZE una tarea separada de captura en alta resolución inmediatamente después de guardar el resultado. El resultado no espera: la posición de la imagen muestra un estado de carga mientras trabaja la cola independiente y la captura terminada se guarda después con el resultado.

La vista previa de Free pertenece exactamente a la ejecución evaluada. La captura en alta resolución a partir de Basic es técnicamente una carga de página independiente realizada justo después, por lo que puede diferir si la página cambia durante ese breve intervalo. La cola reintenta de forma limitada los fallos transitorios y finaliza cada tarea en un máximo de 15 minutos. Si la captura sigue fallando, aparece No se pudo crear la captura de pantalla. La acción inferior cambia a Volver a probar el contenido e inicia un nuevo Accessibility Test. Una tarea terminada o caducada no se reanuda en un momento posterior arbitrario.

El plugin no puede aceptar un diálogo de consentimiento ni fijar cookies por adelantado: solo tu sitio y tu configuración de consentimiento controlan lo que ve la ejecución automática.

• Captura: Un overlay de consentimiento puede seguir visible en la miniatura aunque tu CMP active opciones como cookies para bots/crawlers. Causas habituales: el user-agent no clasifica el cliente de medición en la nube como esperas, otra capa muestra un banner (tema, Tag Manager, scripts adicionales, versión del CMP), o el momento de la captura coincide aún con el overlay.
• Auditorías / puntuación: Un overlay de cookies o de consentimiento puede cambiar mucho el resultado: mientras un banner o un modal bloquee u oculte contenido, gran parte de la página puede quedar fuera del alcance de las comprobaciones automáticas y no todos los elementos se prueban de verdad. Las auditorías y la puntuación pueden diferir claramente de lo que se ve tras aceptar cookies — no solo en la miniatura.
• Próximos pasos prácticos: Revisa la documentación de tu proveedor de consentimiento (bots/crawlers, herramientas de medición, URLs de vista previa o parámetros documentados). Los desarrolladores pueden usar el filtro de WordPress ezzewcag_accessibility_test_cloud_url para añadir solo para el test en la nube parámetros de consulta documentados por el proveedor.

Nota: Las medidas técnicas no sustituyen tu propia revisión de privacidad y cumplimiento. Si dependes de excepciones para bots/crawlers, confirma con el proveedor si el tráfico de medición del Accessibility Test en la nube queda cubierto.

Ocultar el banner de cookies (ajustes del Accessibility Test)

En los ajustes del Accessibility Test puedes activar Banners de cookies en las pruebas. El plugin añade entonces una clave oculta solo a la URL usada en la ejecución en la nube. Tu sitio puede reconocer esa única petición y ocultar el banner de cookies para la medición automática. Las visitas normales no cambian, pero el banner de cookies no se comprueba mientras la opción está activada.

Los servicios compatibles y la solución de problemas se pueden desplegar directamente en el ajuste. En Ajustes técnicos puedes consultar la clave actual. Genera una nueva clave solo si la actual puede haberse dado a conocer.

Para las peticiones de prueba válidas, el plugin envía automáticamente cabeceras de no caché y establece la señal de WordPress DONOTCACHEPAGE. Esto protege las cachés de página que permiten que la petición llegue a WordPress. Solo si una caché previa o una CDN ignora por completo los parámetros de URL debes excluir de esa caché las peticiones que contengan ezzewcag_cmp. Los visitantes normales no necesitan abrir el enlace de prueba para que pueda darse este caso excepcional.

Versiones de banners de cookies y límites del soporte

Fecha de comprobación: 11 de septiembre de 2026. Estos datos se refieren a la ocultación durante el Accessibility Test, no a la compatibilidad general ni al mantenimiento del proveedor. La ocultación también está disponible en Free; un plan de pago no resuelve una versión incompatible del banner.

Banner / versión	Integración y comprobación
Borlabs Cookie 2.x	Integración específica para la estructura antigua del frontend; 2.2.34 comprobada correctamente en una instalación real con la corrección de EZZE y una nueva captura del resultado. No implica que se hayan probado todas las versiones 2.x.
Borlabs Cookie 3.x	Integración independiente mediante las interfaces 3.x. La comprobación con 2.2.34 no acredita ninguna subversión concreta de 3.x.
Borlabs Cookie 1.x	Sin integración documentada ni soporte confirmado. Antes de cambiar, comprueba la versión de destino admitida por el proveedor y el procedimiento de migración.
Complianz, Cookiebot, Real Cookie Banner, iubenda	Integraciones incluidas mediante las interfaces de cada plugin. No hay una lista exhaustiva de versiones probadas ni una versión mínima numérica confirmada. Hay que comprobar la instalación concreta.
CookieYes / GDPR Cookie Consent antiguo	Integración mediante el hook antiguo del plugin. No hay un límite numérico confirmado entre esta integración y la de la aplicación web.
CookieYes conectado a su aplicación web	Otro método elimina el script externo de carga de cdn-cookieyes.com. No cubre automáticamente scripts alojados localmente, modificados o insertados de otra forma.

Otros scripts externos de OneTrust, Osano, Termly, Quantcast Choice, Didomi, TrustArc, Usercentrics, CookieScript y CookieFirst se eliminan mediante dominios de scripts conocidos. No garantiza todas las versiones o formas de instalación. Los banners personalizados y otras integraciones pueden necesitar la adaptación para desarrolladores descrita abajo.

Banner visible: comprobación de versiones y orientación para soporte

1. Recoge el nombre y la versión exacta del banner, la versión de EZZE y su estado de correcciones/compilación, la URL afectada y la fecha y hora de la prueba. «Detectado» confirma la detección del plugin, no la ocultación correcta en esa configuración.
2. Comprueba que la activación de la nube esté completa y la ocultación activada. Después revisa cachés/CDN y banners adicionales del tema, gestor de etiquetas u otros plugins.
3. Para Borlabs 2.x, EZZE debe incluir la corrección de la integración antigua. El paquete Free 1.0.0 generado originalmente no contiene esta corrección posterior; una instalación corregida individualmente puede seguir mostrando 1.0.0. Comprueba el paquete y el registro de cambios. El paquete 1.0.0 generado nuevamente mediante Freemius el 11 de septiembre de 2026 incluye la corrección (registro de compilación: 34634511889). Las descargas anteriores con el mismo número de versión no la incluyen automáticamente. La solución verificada con 2.2.34 no requiere cambiar a Borlabs 3.x.
4. Recomienda actualizaciones concretas: actualizar EZZE solo ayuda si el paquete disponible incluye la corrección pertinente. Actualizar el banner puede ser adecuado para una versión sin integración o una corrección confirmada por el proveedor; comprueba primero la versión de destino y la migración. No inventes versiones mínimas ni prometas que una actualización resolverá el problema sin pruebas.
5. Ejecuta una nueva prueba. Las capturas guardadas no cambian retroactivamente. Si sigue apareciendo el banner, envía los datos anteriores y la nueva captura a soporte, pero nunca la clave secreta de prueba ni una URL que contenga su valor.

Ejemplo de respuesta de soporte: «Borlabs Cookie 2.x necesita la integración correspondiente de EZZE. La ocultación se comprobó con Borlabs 2.2.34 y la corrección de EZZE. Comprueba primero si tu instalación de EZZE contiene esa corrección, activa la ocultación y ejecuta una nueva prueba. No es imprescindible cambiar a Borlabs 3.x para ello».

Para desarrolladores: CMP no integrado en el plugin

1. Parámetro de URL documentado por el proveedor: Si el proveedor documenta un parámetro que desactiva u omite el banner (vista previa, medición, modo bot, etc.), añádelo con el filtro ezzewcag_accessibility_test_cloud_url (ejemplo más abajo). El plugin registra su parámetro secreto con prioridad 15. Usa una prioridad inferior (p. ej. 10) para que ambos acaben en la URL, o superior (p. ej. 20) si tu callback necesita la URL ya con la clave.
2. Hooks PHP documentados: Engancha ezzewcag_accessibility_test_register_cmp_bypass. Solo se ejecuta cuando se detecta un bypass válido (secreto correcto en la cadena de consulta y ajuste activado). En tu callback registra los filtros del CMP para que el banner no cargue solo en esta petición. El plugin dispara la acción al inicio de plugins_loaded e init.
3. Detección personalizada: Si la caché o el proxy eliminan la cadena de consulta pero aún puedes identificar la medición en la nube (p. ej. User-Agent), amplía la detección con el filtro ezzewcag_accessibility_test_cmp_bypass_active. Recibe el booleano por defecto y el nombre del parámetro configurado.
4. Renombrar el parámetro: Solo si tu pila lo exige: filtro ezzewcag_accessibility_test_cmp_bypass_query_arg. El mismo nombre debe usarse al leer el parámetro en el servidor.

En código propio puedes llamar a WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() para comprobar si el contexto de bypass aplica en la petición HTTP actual.

Ejemplo: hooks de un CMP propio mediante la acción del plugin

Sustituye la línea comentada por filtros o llamadas de la documentación para desarrolladores de tu CMP. Este fragmento no se incluye en el plugin. Con el functions.php del tema hijo suele bastar. Usa un MU plugin o un plugin propio pequeño solo si necesitas que el código siga activo al cambiar de tema (o no usas tema hijo).

<?php
/**
* Solo durante un bypass válido del test en la nube (secreto en la URL + ajuste activo).
* Registra los hooks de tu CMP para suprimir el banner solo en esta carga.
*/
add_action(
'ezzewcag_accessibility_test_register_cmp_bypass',
static function () {
if ( ! class_exists( 'WCAG_Accessibility_Test_CMP_Bypass' ) ||
! WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() ) {
return;
}
// Ejemplo: add_filter( 'your_cmp_show_banner', '__return_false' );
}
);

Ejemplo de código (desarrolladores): parámetros de consulta para la prueba en la nube

Este código no va incluido en el plugin. Colócalo en un MU plugin (recomendado: p. ej. wp-content/mu-plugins/wcag-cloud-test-consent-tweaks.php) o en el functions.php del tema hijo. Haz una copia de seguridad antes; solo despliégalo si entiendes el impacto.

Parámetros de consulta solo para la prueba en la nube (filtro del plugin)

Úsalo cuando tu CMP documente un indicador de URL soportado para vistas previas o flujos de consentimiento. Sustituye YOUR_QUERY_KEY y YOUR_QUERY_VALUE por los nombres exactos del proveedor; si no existen, no uses este enfoque. El filtro se aplica a cada ejecución en la nube del Accessibility Test, salvo que añadas tú mismo condiciones en el callback.

<?php
/**
* Only for EZZE WCAG Pro cloud runs: adjust URL before the proxy request.
*
* Customize: YOUR_QUERY_KEY / YOUR_QUERY_VALUE per CMP documentation.
*/
add_filter(
'ezzewcag_accessibility_test_cloud_url',
static function ( $url, $strategy, $post_id, $page_type ) {
return add_query_arg(
'YOUR_QUERY_KEY',
'YOUR_QUERY_VALUE',
$url
);
},
10,
4
);

Lotes manuales: límite diario

Por sitio y día natural (zona horaria de WordPress en Ajustes → Generales), hay como máximo 10 inicios manuales de lote para proteger la infraestructura. Las ejecuciones programadas o tras publicar siguen reglas distintas.

Modos

Prueba individual (Free):

• Prueba una URL
• Puedes buscar en la lista agrupada del selector de contenido. Las categorías y las entradas se desplazan juntas. Pulsa Escape para cerrar la lista y devolver el foco al campo de selección.
• El selector muestra el título y la ruta URL en una sola fila compacta, sin el dominio del sitio actual. La búsqueda también incluye la URL completa. Al pasar el ratón sobre el botón de información o dar foco a una entrada, su título completo y enlace permanente aparecen junto al botón de información. En vistas estrechas se oculta la ruta; el botón de información permite consultar la dirección completa antes de seleccionar el contenido.
• Resultados en la misma vista
• Si la respuesta del servidor se interrumpe en la vista de prueba mientras esta sigue ejecutándose, la vista utiliza consultas breves de estado para esperar esa misma prueba. El resultado terminado aparece automáticamente en la lista, sin recargar la página ni reiniciar la prueba. La recuperación espera hasta diez minutos; si no se completa, puedes actualizar la lista de resultados. Una prueba realmente simultánea sigue bloqueándose.
• Lista detallada de incidencias
• Disponible desde la barra de administración, el editor o la interfaz del plugin
• Si un fallo temporal de transporte, límite de solicitudes o servicio impide que el servicio de pruebas en la nube inicie una prueba, el plugin espera brevemente y vuelve a intentar el inicio exactamente una vez. Solo si ese intento también falla, el mensaje explica que el servicio de pruebas en la nube no está disponible temporalmente. Los errores de cuota, permisos y URL no se reintentan automáticamente.
• Con la prueba móvil activada, la prueba individual se ejecuta en dos pasos separados. Si solo el paso móvil encuentra un fallo temporal de carga o del servicio, el plugin lo reintenta exactamente una vez. Si vuelve a fallar, el resultado de escritorio correcto se conserva y se muestra con un error móvil claro.

Pruebas por lotes (desde Basic):

• Encola muchas URLs desde Basic
• Procesamiento en segundo plano (WP-Cron o Action Scheduler)
• Cada paso siguiente se programa de forma persistente; si una cola en ejecución queda sin un worker activo, el plugin reanuda automáticamente la misma ejecución sin volver a probar las páginas completadas
• Selecciona tipos de contenido, archivos, taxonomías o páginas especiales (p. ej. portada)
• Tabla de resultados con filtros y ordenación
• Las repeticiones sobrescriben los resultados guardados para la misma URL
• Antes de estimar e iniciar, la cola por lotes se deduplica con esa misma URL normalizada; un elemento asociado a contenido publicado de WordPress tiene prioridad sobre uno basado solo en URL
• Si algunos elementos fallan (p. ej. tiempos de espera o errores puntuales), puedes volver a probar con un solo clic todos los elementos que sigan fallando de esa ejecución, desde la lista de errores que se muestra al finalizar
• Si solo falla la vista móvil de un resultado guardado, puedes repetir únicamente ese viewport móvil directamente desde la vista de detalle del resultado
• La actividad en directo mantiene visible un mismo contenido durante toda su secuencia de viewports: tras la prueba de escritorio, el título permanece, el chip de escritorio muestra el resultado terminado y el chip móvil pasa de Preparando a la prueba en curso. El contenido solo se traslada a la lista de finalizados cuando han terminado todos los viewports activados. En las ejecuciones solo para escritorio no aparece ningún chip móvil; entre dos contenidos ya se muestra el siguiente contenido conocido como preparado. Al recargar la página se restaura el mismo estado a partir de los datos persistidos del worker, la cola y las finalizaciones. Si vuelves a activar la actualización automática después de una pausa, el plugin sincroniza primero la vista de resultados actual completa y después reanuda las actualizaciones incrementales.
• La lista de pruebas recién finalizadas de la actividad en directo empieza vacía con cada nuevo lote y solo muestra resultados de esa ejecución. Los resultados nuevos se añaden sin reconstruir las filas existentes en cada consulta de estado; los chips de resultado sin cambios conservan el foco del teclado. Al recargar se restaura la actividad guardada de la misma ejecución.
• Mientras una prueba en la nube esté pendiente, su contenido permanece visible entre las consultas de estado. La espera hasta la siguiente consulta no muestra temporalmente el contenido siguiente.
• Preparando aparece solo hasta que la nube confirma que la vista seleccionada se está ejecutando. Durante la ejecución, su indicador Escritorio o Móvil está activo sin la etiqueta de preparación. Las vistas finalizadas muestran su resultado; la siguiente vista puede mostrar brevemente Preparando antes de comenzar.
• Antes de comenzar la prueba de un contenido, solo se muestra Preparando. Las etiquetas Escritorio y Móvil aparecen al comenzar la prueba. Durante la preparación posterior de la vista móvil, el resultado de escritorio permanece visible y Móvil · Preparando forma un único grupo a su lado.
• Si caduca tu sesión de administración, las actualizaciones en segundo plano se pausan mientras vuelves a iniciar sesión. Los avisos adicionales de sesión no cubren la ventana de acceso de WordPress. Si no hay una ventana de acceso abierta, aparece como máximo un aviso. Tras confirmar el inicio de sesión, las vistas vuelven a actualizarse; las acciones de iniciar, eliminar y cancelar no se repiten automáticamente. El lote continúa en el servidor.

Tras publicar / actualizar:

• Prueba automática opcional al publicar entradas o páginas por primera vez (desactivada por defecto)
• Prueba automática opcional al guardar entradas o páginas ya publicadas desde Basic (desactivada por defecto)
• Roles configurables para ambos (por defecto: administrador, editor, autor)
• Correo opcional tras la prueba al publicar (activado por defecto si el auto-test al publicar está activo) y al actualizar (desactivado por defecto)

Lotes programados (desde Basic):

• Ejecuciones recurrentes (semanal, mensual, intervalo personalizado) desde Basic
• Cadencia configurable
• Elige tipos de contenido, archivos y taxonomías
• Se ejecutan vía WP-Cron o Action Scheduler

Integraciones y permisos

Puntos de acceso:

• Barra de administración: acción rápida de prueba en el front-end
• Panel del editor: en el editor de bloques, la barra lateral «Accesibilidad» muestra los últimos resultados de escritorio y móvil, un enlace a los resultados del plugin y una acción para iniciar la prueba de la URL editada. El editor clásico ofrece el mismo panel en el cuadro «Publicar» si está activado. Solo aparece para los tipos de contenido compatibles y los usuarios autorizados a ejecutar pruebas. El contenido publicado se puede probar; los borradores siguen las reglas documentadas.

Capacidades:

• Quién puede ejecutar pruebas individuales: configurable (por defecto: administrador, editor)
• Quién puede probar contenido de otras personas: configurable (por defecto: solo administrador)
• Quién puede iniciar lotes: configurable (por defecto: solo administrador)
• Quién puede borrar resultados: configurable (por defecto: solo administrador)

Prueba automática al publicar:

• Activar / desactivar (desactivada por defecto)
• Correo opcional tras la prueba (activado por defecto si el auto-test al publicar está activo)
• Elige qué roles disparan la ejecución (por defecto: administrador, editor, autor)

Prueba automática al actualizar (desde Basic):

• Activar / desactivar (desactivada por defecto)
• Se ejecuta al guardar una entrada o página ya publicada
• Usa la misma lista de roles que la prueba al publicar
• Correo opcional tras la prueba al publicar (activado por defecto si el auto-test al publicar está activo) y al actualizar (desactivado por defecto)
• El correo de resultados resume el estado, el contenido probado, las puntuaciones de escritorio y móvil, la fecha y los enlaces directos en un diseño adaptable. En teléfonos, las métricas, los detalles y las acciones se apilan, y también se incluye una alternativa en texto sin formato.

Lotes programados (desde Basic):

• Intervalo: semanal, mensual, personalizado (días)
• Tipos de contenido: p. ej. entrada, página
• Archivos / taxonomías / páginas especiales: según lo ofrezcan los ajustes
• Correo opcional tras cada lote manual o programado: distingue claramente las ejecuciones completadas, fallidas y canceladas, y muestra solo la información pertinente, como páginas procesadas, problemas, duración, tipo de prueba, viewport, iniciador y fechas. Los reintentos y ejemplos de errores solo aparecen cuando existen. Los avisos de límite indican el motivo, el alcance previsto y los pasos siguientes.

ID de soporte para problemas con una ejecución por lotes

Si una ejecución por lotes tarda demasiado, deja de avanzar, falla o termina de forma inesperada, incluye su ID de soporte completo en tu solicitud de soporte. Así se puede identificar la ejecución exacta. Describe brevemente qué ocurrió y el progreso o mensaje de error que viste.

En la página Prueba de accesibilidad, abre Historial de lotes junto a Ayuda. Se abre un panel lateral en el escritorio y un panel inferior en el móvil. La ejecución más reciente está desplegada; puedes desplegar las anteriores individualmente. Cada ejecución conserva su propio resumen con estado, número de páginas, inicio, fin, duración, reintentos, alcance y errores de prueba, además del tipo de prueba, Viewport y usuario que la inició. Las ejecuciones anteriores pueden carecer de datos que aún no se guardaban. El pequeño icono de copia junto al ID de soporte copia solo ese ID. Usa Descargar diagnóstico para guardar los datos. Los correos de finalización también incluyen el ID. Copia siempre la cadena completa que empieza por EW-B-.

El ID de soporte no cambia al reanudarse la misma ejecución. Una ejecución nueva recibe un ID nuevo. Copiar el ID o descargar el diagnóstico no crea una solicitud de soporte.

Comunica los problemas cuanto antes: los resúmenes y los eventos de diagnóstico se conservan durante 90 días y después se eliminan automáticamente. Las ejecuciones anteriores a la introducción de los ID de soporte no reciben un ID retroactivamente; en ese caso, indica tu sitio web y la fecha y hora de inicio de la ejecución afectada.

Resultados

Cada ejecución incluye:

• Puntuación global: puntuación de accesibilidad de 0 a 100
• Semáforo de puntuación en la lista de resultados: 90–100 en verde, 50–89 en amarillo y 0–49 en rojo. El valor numérico siempre permanece visible, por lo que la valoración no se comunica solo mediante el color.
• Categorías: agrupadas por áreas de auditoría
• Redirecciones: el plugin comprueba la ruta de redirección antes de iniciar una prueba en la nube. Una prueba individual muestra primero la URL solicitada y presenta un destino resoluble con su título de WordPress, tipo de contenido localizado y URL enlazada, sin crear una puntuación. Para un destino interno, Probar destino de redirección inicia una prueba confirmada por separado; los destinos externos nunca se prueban. Un resultado completado pertenece al destino, mientras que la URL solicitada permanece visible como procedencia y se utiliza en Volver a probar.
• Filtros de resultados: combina tipo de contenido, tipo de página, estado del contenido, estado de problemas, puntuación, antigüedad y origen de la prueba. «Resultados huérfanos» muestra pruebas cuyo contenido de WordPress asociado ya no está publicado, por ejemplo porque está en la papelera, guardado como borrador o eliminado definitivamente. Estas filas llevan la etiqueta visible «Huérfano» y se pueden eliminar individualmente o en conjunto. Los resultados de URL independientes, archivos y taxonomías con post_id = 0 siguen siendo válidos. El aviso y el filtro cuentan las mismas entradas deduplicadas, por lo que los resultados antiguos del mismo contenido no inflan la cifra. «Sin problemas» solo muestra entradas cuyos resultados de escritorio y móvil no contienen problemas. Los filtros activos aparecen como etiquetas que se pueden quitar individualmente y se conservan durante la sesión del navegador. En teléfonos, el filtro combinado se abre como una hoja inferior; Aplicar confirma el borrador, mientras que Cancelar, Cerrar, Escape, el fondo o deslizar hacia abajo mantiene sin cambios los filtros aplicados.
• Detalles adaptables: en teléfonos, el resultado se abre como un panel inferior enfocado que queda alineado con los bordes izquierdo, derecho e inferior del viewport y conserva esquinas redondeadas solo arriba. La cabecera y la acción de cierre permanecen fijas. El tirador superior se puede arrastrar hacia abajo con el pulgar para cerrarlo; el panel se desliza hacia abajo mientras se desvanece el oscurecimiento y la página permanece visible. En pantallas grandes permanece integrado en la lista de resultados.
• Puntuación actual y panel: solo los resultados de contenido publicado de WordPress y los resultados válidos basados solo en URL participan en las métricas actuales, Analytics, AI Insights e informes. El contenido en papelera, borrador o eliminado no afecta a la puntuación actual. Su historial de ejecuciones se conserva para la trazabilidad y no puede volver al alcance actual al reagregar.
• Limpieza: al eliminar resultados actuales o huérfanos, el plugin elimina también sus incidencias, explicaciones y resultados guardados de auditorías/WCAG. Los registros históricos permanecen intactos; no se eliminan por accidente otros viewports actuales ni resultados de otros usuarios.
• Selector escritorio/móvil: la puntuación, la captura, el número de problemas y los detalles de comprobación corresponden siempre a la vista seleccionada.
• Grupos de comprobaciones: las comprobaciones fallidas, manuales, superadas y no aplicables se muestran con su cantidad y se pueden desplegar por separado. En los resultados nuevos, los grupos manuales, superados y no aplicables también incluyen los nombres y las descripciones localizados de cada comprobación. Las comprobaciones no aplicables explican por qué dos páginas pueden tener un número diferente de comprobaciones evaluadas automáticamente.
• Inspector de accesibilidad: la acción global Abrir Inspector abre todos los elementos afectados en la página probada; el icono de sombrero y gafas abre el mismo Inspector en el hallazgo exacto. Los controles anterior, siguiente y resumen permiten recorrer todos los elementos, y los distintos hallazgos de un mismo destino DOM siguen siendo seleccionables. El Inspector no modal distingue coincidencias visibles, elementos ocultos presentes en el DOM, elementos estructurales sin cuadro propio, selectores ausentes y selectores ambiguos. Muestra el elemento y su rol, el tamaño, la causa de visibilidad y una estimación del árbol de accesibilidad. En escritorio, el Inspector comienza alineado con los bordes superior, derecho e inferior del viewport disponible y permanece debajo de la barra de administración visible de WordPress. Un botón compacto con icono abre las opciones para acoplarlo a la derecha, izquierda, parte superior o inferior, mientras que otro botón con el icono de ojo tachado oculta el Inspector; la preferencia se guarda únicamente en el navegador. Los paneles laterales añaden una navegación numerada por todos los elementos afectados, y los paneles superior e inferior colocan en paralelo la navegación, el contexto y la solución. Los teléfonos mantienen el panel inferior fijo sin selector de posición. Al ocultarlo, el panel se reduce a un botón etiquetado en el borde y conserva el destino, el resaltado y la vista previa del navegador; ese botón lo restaura. No existe una acción de cierre permanente y Escape mantiene abierto el Inspector asociado al resultado. Todos los planes pueden abrir AI Element Fix o generarlo dentro de su cupo. La vista previa del navegador solo está disponible para atributos de nombre accesible permitidos, colores de texto o fondo estrictamente limitados en hallazgos de contraste y un subrayado permanente para link-in-text-block. La vista previa del enlace puede incluir además exactamente un color de texto hexadecimal de seis dígitos; el color por sí solo no se acepta. Una vista previa de color muestra los colores y las relaciones de contraste antes y después, calcula el umbral aplicable e indica por escrito si se cumple, no se cumple o no puede verificarse de forma fiable. Los fondos complejos permanecen como instrucciones manuales. Si no puede derivarse un parche seguro, el Inspector identifica expresamente la sugerencia como instrucción manual. Cada vista previa es temporal y se revierte al deshacer o navegar; ocultar, restaurar y volver a acoplar la conserva. Nunca guarda contenido ni estilos. No se aplica HTML, JavaScript ni CSS arbitrario de la IA. La ayuda gratuita Explicación y solución no requiere una solicitud de IA. La preferencia de movimiento reducido desactiva las animaciones y el desplazamiento suave.
• Navegación y gravedad del Inspector: en un panel lateral, Resumen es la primera acción de la barra, por encima de los elementos afectados numerados. El punto de color que indica la gravedad de cada número se repite como texto localizado en el nombre accesible de la acción, en la entrada del resumen y en el hallazgo activo, de modo que el significado no depende solo del color.
• Acciones de vista previa del Inspector: al principio solo está disponible Aplicar vista previa. Tras aplicarla correctamente, la acción se sustituye por Deshacer vista previa sin restablecer la posición de desplazamiento de la zona del Inspector.
• Presentación del Inspector: cuando una zona necesita desplazamiento, se conserva el uso nativo con rueda, tacto y teclado, mientras se muestra una barra de desplazamiento estrecha superpuesta. Al acoplarlo arriba o abajo, el contexto del elemento y la solución se desplazan de forma independiente y cada columna muestra su propia barra cuando existe desbordamiento. En teléfonos, la zona del tirador y el encabezado forman una superficie continua con el mismo color; un gesto deliberado hacia abajo desde el tirador o desde una zona no interactiva del encabezado oculta el Inspector sin finalizar la sesión de inspección. En enlaces y otros elementos en línea que ocupan varias líneas, el Inspector resalta cada fragmento visible por separado en lugar de encerrar texto ajeno entre los fragmentos dentro de un rectángulo grande. Si un elemento seleccionado está oculto únicamente por una animación de entrada reconocida, el Inspector se desplaza específicamente hasta él, espera durante un tiempo limitado a que aparezca y vuelve a evaluarlo. No abre menús, diálogos, detalles ni pestañas cerrados intencionadamente. Si todavía no existe un nodo de destino creado de forma diferida, primero se desplaza hasta el ancestro existente más cercano del selector; solo después puede ejecutarse un recorrido alternativo limitado, que se detiene al encontrar una coincidencia y vuelve a la posición inicial si falla.
• Cuota de AI Element Fix: en el Inspector, todos los usuarios ven el cupo restante para AI Element Fix; las explicaciones de IA ya consumidas siguen contabilizadas. El contador se actualiza automáticamente después de una nueva generación y muestra estados explícitos de carga y error.
• Metadatos: la URL probada, el usuario que ejecutó la prueba y el tipo de inicio (por ejemplo, Manual, Batch o Programado) permanecen visibles de forma compacta. En pantallas estrechas, las URL largas se acortan al principio y se pueden desplegar por completo cuando sea necesario; el botón de enlace independiente abre la página en una pestaña nueva.

Gestión de redirecciones

• Prueba individual: mostrar el aviso de redirección no consume cuota de prueba. Un destino interno solo se prueba después de una confirmación explícita. El servidor vuelve a resolver el destino al usar la acción, de modo que el navegador no pueda introducir un destino cambiado o externo.
• Pruebas por lotes, programadas, tras publicar y tras actualizar: Probar automáticamente destinos de redirección internos está desactivado de forma predeterminada en los ajustes de la prueba de accesibilidad. Si está desactivado, los elementos redirigidos se notifican como omitidos sin puntuación ni hallazgos. Si está activado, solo se prueban automáticamente destinos del mismo dominio.
• Atribución: una prueba de destino completada se guarda únicamente para la URL de destino final y su identidad de contenido de WordPress. La URL de origen es metadato, no un segundo resultado.
• Seguridad y duplicados: los destinos externos no se solicitan después de su respuesta de redirección. Los bucles, destinos no válidos, ubicaciones ausentes, URLs inaccesibles y cadenas de redirección excesivas son errores. Si varias URLs de origen llevan al mismo destino en un lote, ese destino se prueba una sola vez.

Ejemplos

Ejemplo 1: línea base del sitio

Ejecuta un lote sobre plantillas clave, corrige los problemas recurrentes más importantes y vuelve a probar.

Ejemplo 2: Tras publicar

Activa las pruebas automáticas para que las entradas nuevas obtengan puntuación sin clics manuales.

Ejemplo 3: Monitorización

Programa lotes mensuales y revisa Analytics para detectar regresiones.

Ejemplo 4: Flujo editorial

Permite a los editores ejecutar pruebas individuales en sus propias entradas mientras los lotes quedan solo para administración.

Consejos

• Realidad: las pruebas automáticas no encuentran todos los problemas WCAG: la revisión manual y experta sigue siendo esencial.
• Usa el historial para seguir el progreso
• Corrige primero lo crítico o grave
• Si alcanzas el límite de URLs, mejora el plan o prioriza plantillas de mucho tráfico
• Las ejecuciones en segundo plano no deberían bloquear la navegación normal
• Combina comprobaciones puntuales (páginas cambiadas) con barridos programados

Nota: ningún comprobador automático demuestra el cumplimiento total de WCAG. Úsalo como parte de un programa de accesibilidad más amplio.

Disponible para: Roles configurables (por defecto: administrador) Free

Pruebas por lotes: desde Basic

Pruebas programadas: desde Basic

Consulta la guía paso a paso sobre la tarjeta del elemento, el árbol de accesibilidad y la vista previa: Inspector de accesibilidad: uso y explicación de los datos.