Preguntas Frecuentes

Conceptos

¿Cuál es la diferencia entre un proyecto con Git y un proyecto sin Git?

Developer Hub organiza sus resultados de manera diferente dependiendo de si sus pruebas utilizan Git:

• Un proyecto con Git asocia los resultados de accesibilidad con ramas y confirmaciones, lo que te permite rastrear problemas hasta cambios específicos en el código.
• Un proyecto sin Git organiza los resultados como una serie de ejecuciones de prueba ordenadas por marca de tiempo, sin ningún dato de Git.
• Los datos de Git están disponibles cuando se utiliza Axe Watcher, Axe CLI o Axe DevTools para las API web (que cargan resultados a través de la CLI). Los proyectos móviles siempre son sin Git.

Consulta Comprenda Sus Resultados y las entradas del glosario para Git y sin Git para más detalles.

¿Qué es el umbral a11y y cómo lo configuro?

El umbral a11y refleja la tolerancia de su organización a los problemas de accesibilidad y determina qué se considera como una falla en su pipeline de CI/CD:

• Se calcula a partir de dos criterios: si contar todos los problemas o solo los nuevos y qué niveles de impacto incluir (el nivel Crítico siempre se incluye).
• Solo los administradores de proyectos pueden configurar el umbral.

Consulta Cambiar el Umbral A11y para obtener todos los detalles.

¿Qué significan los niveles de impacto (Crítico, Grave, Moderado, Menor)?

Cada violación de accesibilidad se asigna a uno de cuatro niveles de impacto, de más a menos severo:

• Crítico: Los usuarios con discapacidades están completamente bloqueados para acceder o interactuar con una función.
• Grave: Los usuarios con discapacidades enfrentan barreras significativas al interactuar con el sitio.
• Moderado: Existen algunas barreras, pero el contenido básico sigue siendo accesible.
• Menor: Problemas menos graves que aún requieren resolución para el cumplimiento total.

Consulta el Glosario para definiciones detalladas.

¿Por qué se siguen reportando los mismos problemas como nuevos?

Para decidir si un problema es nuevo, Developer Hub compara cada resultado con la ejecución anterior por regla, selector de elementos y URL, como se describe en Duplicado en el glosario. Si el mismo problema en el mismo elemento se reporta como nuevo en cada ejecución, uno de esos factores está cambiando entre ejecuciones. Hay dos causas comunes.

La URL cambia entre ejecuciones. La URL se compara en su totalidad, por lo que un ID de sesión, una marca de tiempo, un parámetro para evitar el almacenamiento en caché o cualquier otro valor dinámico en la cadena de consulta hace que cada ejecución parezca una página diferente, y cada problema en una URL que no se había visto antes se reporta como nuevo. No hay ninguna configuración que normalice las URLs antes de compararlas, por lo que la solución es hacer que las URLs que visitan tus pruebas sean determinísticas: elimina o corrige los parámetros volátiles en la configuración de tus pruebas para que la misma página genere la misma URL en cada ejecución.

Los IDs o las clases del elemento cambian entre ejecuciones. Los frameworks que generan identificadores como #component-a1b2c3d4 o .form-field-xyz789 en cada renderizado cambian el selector del elemento, por lo que ya no coincide con el elemento registrado previamente. Configurar la opción de ejecución ancestry a true soluciona esto, porque el selector de ascendencia describe el elemento por su posición en el árbol DOM y no contiene IDs ni clases:

axe: {
  runOptions: {
    ancestry: true
  }
}

Consulta Uso de Selectores Dinámicos para la explicación completa, incluyendo la configuración de Java y las compensaciones de habilitar ancestry.

Comparaciones

Cada conteo de "nuevo problema" o "problema resuelto" en Developer Hub proviene de comparar el escaneo actual con un escaneo línea base. Qué escaneo cuenta como línea base depende de dónde estés buscando:

• Comparaciones entre ramas aparecen en la vista de Ramas. Comparan el escaneo más reciente de tu rama con el último ejecución de pipeline en la rama predeterminada. Una ejecución de pipeline es un escaneo activado por tu pipeline CI/CD, a diferencia de una ejecución local desde la máquina de un desarrollador; Developer Hub señala estas de forma separada para saber siempre cuál escaneo de la rama predeterminada es autoritativo. Esto responde a "¿qué cambiaría si fusiono ahora mismo?"
• Comparaciones dentro de la rama aparecen en la vista de Commits. Comparan el escaneo de un commit con el escaneo del commit anterior que tiene resultados en la misma rama, lo cual no es necesariamente el commit literal anterior en tu historial de Git: un commit sin escaneo se omite. Esto responde a "¿qué introdujo o solucionó este commit específico?"

El Acción de GitHub no es un tercer tipo de comparación. Los conteos que publica en una solicitud de extracción son la comparación dentro de la rama para el commit actual, no una comparación contra la rama predeterminada, lo cual es una fuente común de confusión ya que se espera a menudo que una verificación de PR compare contra la rama en la que se fusionaría.

Consulta Comprenda Sus Resultados para obtener el panorama completo.

¿Cómo determino qué está cambiando de una versión a otra?

La vista de Ramas en un proyecto con Git le permite rastrear los cambios de accesibilidad entre versiones usando una comparación entre ramas:

• El commit escaneado más reciente de cada rama se compara con la ejecución más reciente del pipeline en su rama predeterminada.
• La comparación muestra el número total de problemas, nuevos problemas introducidos, problemas resueltos y cualquier cambio en el número de estados de página escaneados.

Para ver qué cambió en las confirmaciones individuales dentro de una rama, consulta ¿Cómo puedo ver qué ha cambiado de commit a commit dentro de una rama?

¿Cómo puedo determinar cuál será el impacto de una solicitud de extracción?

Ejecute su suite de pruebas en la rama de la solicitud de extracción para que los resultados aparezcan en Axe Developer Hub:

• En la vista de Ramas, cada rama que no sea la predeterminada muestra una comparación entre ramas y la rama predeterminada, mostrando nuevos problemas introducidos, problemas resueltos y la diferencia total.
• Si utilizas el Acción de GitHub, puede publicar automáticamente un comentario en el PR con un resumen y un enlace a los resultados completos.

Para profundizar en lo que cada confirmación en la rama cambió, consulta ¿Cómo puedo ver qué ha cambiado de commit a commit dentro de una rama?

¿Cómo puedo ver qué ha cambiado de commit a commit dentro de una rama?

Desde la vista Ramas, haz clic en Ver Commits en cualquier rama para ver sus confirmaciones individuales escaneadas. A diferencia de las comparaciones entre ramas en la vista Ramas, la vista Confirmaciones usa comparaciones dentro de una rama:

• Cada commit se compara con el commit escaneado anterior en esa rama, mostrando nuevos problemas, problemas resueltos y cambios en los estados de página.
• Solo aparecerán los commits en los que se ejecutó la suite de pruebas.

Para ver cómo se compara la rama completa con la rama predeterminada, consulta ¿Cómo puedo comparar una rama con la última ejecución de CI/CD en la rama predeterminada?

¿Cómo puedo comparar una rama con la última ejecución de CI/CD en la rama predeterminada?

La vista de Ramas realiza automáticamente una comparación entre ramas para cada rama que no sea la predeterminada contra la última ejecución de la canalización de la rama predeterminada:

• Esto requiere que un administrador del proyecto haya configurado Axe Watcher para ejecutarse en la rama predeterminada como una ejecución de canalización.
• La comparación muestra problemas totales, nuevos problemas, problemas resueltos y diferencias en los estados de página.

Para ver qué cambió en las confirmaciones individuales dentro de esa rama, consulta ¿Cómo puedo ver qué ha cambiado de commit a commit dentro de una rama?

¿Cómo consigo resultados de comparación precisos antes de crear una solicitud de extracción?

Para obtener la comparación entre ramas más precisa antes de fusionar, mantenga su rama de características actualizada con la rama predeterminada:

1. Fusiona la rama predeterminada en tu rama de características (por ejemplo, git merge main) antes de ejecutar tu suite de pruebas.
2. Envíe el commit de fusión para que Axe Developer Hub pueda escanear la rama actualizada.
3. La vista de Ramas luego comparará su rama contra la última ejecución de la canalización en la rama predeterminada, mostrando solo los cambios de accesibilidad que realmente introduce su rama.

Si su rama de características está detrás de la rama predeterminada, la comparación puede mostrar problemas que ya fueron solucionados en la rama predeterminada pero que aún no se han fusionado en su rama de características. Fusionar la rama predeterminada primero elimina esos falsos positivos y reduce las sorpresas cuando se fusiona la solicitud de extracción.

¿Por qué veo problemas reportados como nuevos o resueltos cuando se ejecutó un conjunto diferente de pruebas?

Una comparación solo tiene sentido cuando el mismo conjunto de pruebas se ejecutó en ambas comparaciones:

• Si una ejecución visita una página que la ejecución de línea base nunca visitó, cada problema en esa página se reporta como nuevo, porque no hay nada con lo que compararlo.
• Si una ejecución omite una página que la línea base cubrió, los problemas de esa página aparecen como resueltos aunque nadie haya solucionado nada, ya que simplemente no fueron probados.
• Dos ejecuciones que cubren suites de pruebas genuinamente diferentes no deberían compararse en absoluto; el resultado no te dirá nada útil.

Esto no es algo que una configuración pueda solucionar. Consulta Mejores prácticas para comparaciones precisas para saber cómo configurar tu suite de pruebas para que las comparaciones sigan siendo significativas.

Mejores prácticas para comparaciones precisas

• Usa un proyecto por cada conjunto de pruebas. Un proyecto debe corresponder a un conjunto de pruebas. Apuntar varios conjuntos a un proyecto significa que cada ejecución se compara con una línea base producida por un conjunto diferente de pruebas, y los conteos de nuevos y resueltos dejan de tener sentido.
• Ejecuta el mismo conjunto de pruebas cada vez. Cambiar lo que cubre el conjunto cambia lo que la comparación puede decirte. Cuando el conjunto crece legítimamente, espera un aumento único en nuevos problemas en la ejecución que agrega la cobertura.
• Configura una ejecución de pipeline en tu rama predeterminada. Las comparaciones entre ramas miden una rama contra la última ejecución de pipeline en la rama predeterminada. Sin una, no hay línea base en absoluto, y cada problema se reporta como nuevo, lo cual es la versión más confusa de este síntoma. Configurar esto es una tarea de administración de proyectos; consulta Información de la pipeline.

CI/CD

¿Cómo me aseguro de que no se fusionen nuevos problemas de accesibilidad en mi código?

Integre Axe Developer Hub en su canalización de CI/CD para que las verificaciones de accesibilidad se ejecuten automáticamente en cada commit o solicitud de extracción:

• Si utilizas GitHub, el Acción de GitHub de Axe Developer Hub puede bloquear PRs que introduzcan errores de accesibilidad.
• Para otras plataformas como GitLab o Bitbucket, utiliza el API de Servicio REST para consultar resultados y fallar tu canalización cuando se detecten problemas.
• Puedes ajustar qué se considera un fallo configurando el umbral de accesibilidad (a11y).

¿Cómo integro Axe Developer Hub con mi canalización de CI/CD si no uso GitHub?

Puede usar la API de servicio REST para integrarse con cualquier plataforma de CI/CD:

• El API de Servicio REST te permite consultar Axe Developer Hub para obtener resultados después de ejecutar tu suite de pruebas.
• La API devuelve el conteo de problemas, nuevas violaciones, violaciones resueltas y un enlace a los resultados completos en Developer Hub.
• Puedes usar esta respuesta para aprobar o rechazar tu pipeline en GitLab, Bitbucket, Jenkins o cualquier otra plataforma.

Gestión de Proyectos

¿Cómo puedo ver los escaneos de accesibilidad de otros miembros del equipo en un proyecto?

Todos los miembros del proyecto pueden ver todos los resultados dentro de un proyecto compartido una vez que han sido añadidos:

• Agrega miembros del equipo a través de la página de configuración de Miembros.
• En los proyectos Git, la vista de Ramas muestra los resultados agrupados por clave de API, para que puedas ver quién realizó cada escaneo.

Para obtener detalles sobre roles y permisos, consulta Configurar Proyectos para Uso del Equipo.

¿Cómo exporto mis resultados de accesibilidad?

Developer Hub ofrece varias maneras de exportar tus datos:

• Desde la vista de resumen de problemas, haz clic en el botón Exportar Problemas para descargar los resultados como CSV o JSON.
• Para acceso programático, utiliza el API de Servicio REST para consultar resultados para una confirmación y un proyecto específicos.

Consulta Obtener Resultados de Forma Programática para más opciones.