Glosario del Centro para Desarrolladores de Axe

a11y

Abreviatura basada en números (o numerónimo) para la palabra "accessibility", donde "11" (once) representa el número de caracteres entre la "a" inicial y la "y" final en accessibility. Se pronuncia como ally.

Clave API

Para la autorización, generará un clave API en Configuración de cuenta de Axe. Puede utilizar la misma clave API para varios proyectos, aunque debe usar una clave API del Axe Developer Hub solo para proyectos web y una clave API de Axe DevTools Mobile solo para proyectos móviles.

Trate su clave API como una credencial secreta: no la incluya en el control de versiones ni la comparta, y guárdela en una variable de entorno o en el administrador de secretos de su plataforma CI/CD.

Centro para Desarrolladores de Axe

Centro para Desarrolladores de Axe le permite crear nuevos proyectos de prueba y le muestra los resultados de sus ejecuciones de pruebas de accesibilidad. Puede crear tantos proyectos como necesite para ver y gestionar la accesibilidad en sus sitios web y aplicaciones móviles.

Línea de base

Una línea de base es el escaneo anterior que Developer Hub mantiene constante para que una comparación pueda medir lo que cambió. Qué escaneo sirve como línea de base depende del tipo de comparación: una comparación entre ramas utiliza el ejecución de pipeline más reciente en la rama predeterminada, y una comparación dentro de la rama, junto con la Acción de GitHub, utiliza el escaneo del commit anterior que tiene resultados en la misma rama.

Mejores Prácticas

Las mejores prácticas de Deque son técnicas probadas que ofrecen resultados de accesibilidad deseados cuando faltan o son insuficientes los métodos formales específicos. Aunque no están oficialmente incluidas en ningún conjunto de reglas de accesibilidad establecido, seguir las mejores prácticas de Deque puede mejorar la accesibilidad y la calidad general de la página web evaluada. Cabe destacar que el incumplimiento de las pautas de mejores prácticas de Deque no indica automáticamente un fallo. Además, se requiere juicio experto para considerar la adecuación en el contexto de los objetivos de la aplicación, sitio o página. A veces, la técnica de accesibilidad de mejores prácticas no es aplicable o práctica para resolver un problema específico. Vea Mejores Prácticas para las reglas que conforman el conjunto de reglas de mejores prácticas.

ID de Construcción

El ID de construcción se genera automáticamente como un UUID cuando el usuario no lo proporciona, y se utiliza para vincular escaneos como una única sesión de prueba. Al ejecutar un conjunto de pruebas a través de múltiples máquinas o entornos, proporcionar un ID de construcción vinculará todas estas ejecuciones y se mostrará como una única sesión en Developer Hub.

Comparación entre ramas

Una comparación entre ramas compara el escaneo más reciente de una rama con el ejecución de pipeline más reciente en la rama predeterminada del proyecto. Aparece en la vista de Ramas y muestra qué cambiaría si la rama se fusionara ahora mismo.

Forma de Datos

El forma de datos de un proyecto es ya sea repositorio Git o Sin Git: si sus resultados contienen información de Git (repositorio, rama y commit) o no. La forma de datos de un proyecto se establece por su bloqueo de proyecto.

Duplicado

Un duplicado es el mismo problema de accesibilidad observado en el mismo nodo del modelo de objeto de documento (DOM) en múltiples estados de página. Si corrige un problema con duplicados, todos sus duplicados desaparecerán porque todos son el mismo problema.

Dos resultados se consideran el mismo problema cuando coinciden los tres siguientes:

• La regla que se violó.
• El elemento. Axe Developer Hub identifica el elemento por su selector CSS y su XPath, y también por su selector de ascendencia cuando ancestry está habilitado; una coincidencia en cualquiera de estos es suficiente.
• El URL de la página, comparado en su totalidad, incluyendo cualquier cadena de consulta.

No se compara nada más. En particular, el título de la página y el HTML del elemento no afectan si un resultado se trata como duplicado.

Actualmente, la desduplicación se aplica solo a proyectos web. Los resultados móviles no tienen selector CSS, por lo que esta comparación nunca coincide, y cada resultado móvil se trata como nuevo en cada comparación, sin ninguna configuración para cambiar eso.

La misma comparación determina si un resultado web es nuevo: un resultado que no coincide con nada en la línea de base aplicable se cuenta como nuevo. Vea ¿Por qué los mismos problemas siguen reportándose como nuevos? para corregir esto.

Pruebas e2e

Las pruebas de extremo a extremo, o e2e, se refieren a probar toda la funcionalidad de la aplicación web probando su implementación en el mundo real. Con Axe Developer Hub, puede probar escenarios e2e para problemas de accesibilidad.

Reglas Experimentales

Las reglas experimentales aún se están desarrollando y probando para abordar nuevas tecnologías o un mayor entendimiento y conciencia de los problemas de accesibilidad. No se debe confiar en estas reglas en entornos de producción porque aún están en desarrollo y son propensas a falsos positivos. Eventualmente, las reglas de este conjunto podrían formar parte de los estándares de accesibilidad. Las reglas experimentales están desactivadas por defecto. Vea Reglas Experimentales para las reglas que conforman este conjunto en la última versión de axe-core.

repositorio Git

repositorio Git es un forma de datos al que un proyecto de Developer Hub puede bloquearse: el conjunto de pruebas del proyecto utiliza un repositorio Git. Usar Git te permite asociar defectos de accesibilidad con código en diferentes ramas y en commits específicos, lo que ayuda en su resolución.

Sin Git

Sin Git es el otro forma de datos al que un proyecto de Developer Hub puede bloquearse: el conjunto de pruebas del proyecto no usa un repositorio Git. Aunque no es necesario, un repositorio Git te permite asociar defectos de accesibilidad con cambios específicos en el código, ayudando en su resolución.

Impacto

A cada violación de accesibilidad se le asigna un nivel de impacto, categorizado en cuatro niveles de menor a mayor impacto: leves, moderados, grave y crítico. Esta métrica ayuda a priorizar los esfuerzos de remediación, y los expertos en accesibilidad de Deque asignan un nivel de impacto a cada tipo de violación por defecto.

Los defectos con niveles de impacto grave o crítico presentan barreras significativas o insuperables para los usuarios con discapacidades, con la mayor responsabilidad legal. Aunque los problemas leves y moderados no son tan severos, siguen siendo cruciales para el cumplimiento y abordar las necesidades de las personas con discapacidades.

Los cuatro niveles utilizados para categorizar el impacto de los problemas de accesibilidad son:

1. Leve: Problemas que afectan a los usuarios con discapacidades menos que los problemas moderados, pero que aún requieren resolución para un cumplimiento total.

2. Moderado: Existen algunas barreras para los usuarios con discapacidades, pero no les impedirían acceder al contenido o flujos básicos. Estos problemas pueden hacer que su organización sea vulnerable a acciones legales y deben remediarse antes de alcanzar un cumplimiento total.

3. Grave: Los usuarios con discapacidades enfrentarán barreras significativas al interactuar con el sitio, causando frustración y dificultad para acceder al contenido relacionado. La remediación debe ser una alta prioridad para evitar acciones legales.

4. Crítico: Los usuarios con discapacidades están completamente bloqueados para acceder o interactuar con una característica en la página web, haciendo que el contenido sea inaccesible y dejando a su organización altamente vulnerable a demandas. La remediación de problemas críticos debe ser una máxima prioridad.

Suite de Pruebas Modificada

Un suite de pruebas modificada es un conjunto de pruebas que ha cambiado según las instrucciones proporcionadas por Axe Developer Hub al crear un nuevo proyecto. Modificar su conjunto de pruebas le permite añadir pruebas de accesibilidad a su conjunto de pruebas existente con cambios mínimos en el propio conjunto de pruebas.

Necesita revisión

Un resultado Necesita revisión es aquel en el que axe-core no pudo determinar con certeza si algo es una violación, por lo que una persona necesita inspeccionarlo. Vea Necesita revisión en el glosario de Axe DevTools para Web para la definición completa. El Hub de Desarrolladores de Axe no muestra los resultados de Necesita Revisión en su interfaz de usuario ni los incluye en ningún total de problemas o en la puntuación de accesibilidad. Aparecen solo en el Exportación universal JSON de Axe y en los resultados de formato completo devueltos por el API de Sesiones y Resultados.

Administrador Organizacional

Un administrador organizacional (administrador de la organización) es un usuario con privilegios administrativos para toda su empresa en Axe Account. Los administradores de la organización pueden ver todos los proyectos en su empresa y gestionar a los miembros del proyecto y la configuración, independientemente de si son miembros de un proyecto dado. El estatus de administrador de la organización tiene prioridad sobre los roles a nivel de proyecto. Los administradores de la organización deben tener una licencia activa de Axe Developer Hub o Axe DevTools for Mobile para crear nuevos proyectos o enviar resultados a los proyectos de los que son miembros en Axe Developer Hub, pero pueden gestionar proyectos existentes sin una licencia.

Estado de la Página

El estado de la página se refiere al estado del modelo de objeto de documento (DOM) de una página web en un momento específico. Ver diferentes estados de página es útil para sitios web complejos con pantallas de inicio de sesión o UI dinámicas, como aplicaciones de una sola página (SPAs). Ejemplos de estado de DOM incluyen:

• La visibilidad de los elementos
• El contenido de los elementos
• El estado marcado de los botones de opción y las casillas de verificación

Cuando usas Watcher, el paquete vuelve a escanear las páginas web cada vez que detecta cambios en el DOM y guarda un nuevo estado de la página cada vez.

Ejecución de pipeline

Una ejecución de pipeline es un escaneo desencadenado por un pipeline de CI/CD, en lugar de una ejecución local desde la máquina de un desarrollador. Developer Hub marca por separado las ejecuciones de pipeline, por lo que siempre sabe qué escaneo de una rama es autoritativo. Se requiere una ejecución de pipeline configurada en la rama predeterminada del proyecto para que las comparaciones entre ramas tengan una línea de base; sin una de estas, cada problema se reporta como nuevo. Vea Información de pipeline y Axe Watcher en Entornos de Integración Continua (CI).

Proyecto

Un proyecto en Axe Developer Hub contiene resultados de accesibilidad, información sobre la ejecución de pruebas y datos de Git (ramas y commits). Creas y nombras un nuevo proyecto en Developer Hub, lo que genera un ID de Proyecto que se usará con tus pruebas para identificar el proyecto y asociar los datos de resultados con el proyecto. Una vez que un proyecto ingiere su primera sesión exitosa, su forma de datos y, para proyectos Git, su repositorio, son fijados por su bloqueo de proyecto.

Administrador del proyecto

Un administrador del proyecto es un miembro del proyecto con permisos elevados. Los administradores del proyecto pueden hacer todo lo que un miembro del proyecto puede, además de gestionar la configuración del proyecto, agregar o eliminar miembros y cambiar roles de miembros. Al usar Axe Watcher, se requiere la clave API de un administrador del proyecto para ejecutar pruebas en una tubería.

ID del proyecto

Un ID del proyecto se genera automáticamente cuando agregas un nuevo proyecto, para asociar tus datos de resultados con ese proyecto. Se requieren tanto un ID de Proyecto como una clave API para enviar resultados de accesibilidad a Developer Hub. Asigna un ID de proyecto a un conjunto de pruebas/repositorio: esto es implementado por el bloqueo de proyecto, que fija la forma de datos y el repositorio de un proyecto después de su primera sesión exitosa.

Bloqueo de Proyecto

Una vez que un proyecto ingiere su primera sesión exitosa, se bloqueos a la forma de datos de esa sesión y, para proyectos Git, al repositorio de esa sesión. Un proyecto bloqueado rechaza cualquier ejecución posterior con una forma de datos diferente o un repositorio diferente en la ingestión; los resultados no se guardan. La configuración del proyecto muestra la forma de datos bloqueada y el repositorio como solo lectura. Consulta Ejecución Rechazada: La Forma de Datos o el Repositorio No Coincide con el Proyecto.

Miembro del proyecto

Un miembro del proyecto es un usuario que ha sido agregado a un proyecto de Axe Developer Hub. Los miembros del proyecto pueden ejecutar pruebas y ver resultados dentro del proyecto. Los miembros deben tener una licencia activa para acceder al proyecto.

Escaneo

Un escaneo son los resultados de accesibilidad que Developer Hub recibe al probar su producto, y lo que cubre un escaneo varía según el tipo de proyecto.

Para proyectos web, un escaneo es el conjunto completo de resultados que su suite de pruebas produce en una ejecución, independientemente de cuántas páginas visite en el camino, enviado a Developer Hub a través de Axe Watcher, las Axe DevTools para Web CLI, o las APIs Web, que se suben a través de la CLI. Cada página que inspecciona puede producir una o más estados de página, una para cada estado DOM distinto detectado, como cuando una aplicación de una sola página cambia de estado sin una recarga de página; el escaneo es la colección completa de estados de página de esa ejecución.

Para proyectos móviles, un escaneo es el resultado de probar una sola pantalla de la aplicación con el Axe DevTools Mobile Analyzer. Probar varias pantallas en una misma sesión produce varios escaneos, que se agrupan bajo una sola sesión.

SHA

Cuando crea un commit con Git, se crea un ID para identificar de manera única el commit. Este ID único se llama un SHA (nombrado así por los Algoritmos de Hash Seguro, un grupo de funciones hash criptográficas).

Etiqueta

Un etiqueta agrupa reglas que pertenecen a una directriz específica de accesibilidad, como WCAG. Para obtener más información sobre las reglas y las etiquetas a las que pertenecen esas reglas, vea Descripciones de Reglas de axe-core

WCAG

WCAG, o Pautas de Accesibilidad para el Contenido Web, son un conjunto de directrices desarrolladas por el World Wide Web Consortium (W3C) para ayudar a hacer que el contenido web sea más accesible para personas con discapacidades. Estas directrices proporcionan un marco para crear sitios web y contenido digital accesibles para personas con una amplia gama de discapacidades.

Los tres niveles de conformidad de las WCAG se definen por un conjunto de criterios de éxito que describen elementos específicos del contenido web que deben cumplirse para alcanzar ese nivel de conformidad. El nivel de conformidad A es el mínimo, mientras que el nivel de conformidad AAA es el más estricto. El nivel de conformidad AA requiere conformidad con los criterios de éxito de los niveles A y AA. La conformidad con los tres niveles de criterios de éxito (A, AA y AAA) es necesaria para la conformidad con el nivel AAA.

WCAG 1.0 fue la primera versión de estas pautas y se publicó en 1999. WCAG 2.0 se publicó en 2008 y proporcionó pautas más completas para hacer que el contenido web sea accesible a personas con una gama más amplia de discapacidades.

WCAG 2.1 se publicó en 2018. Se basa en las versiones anteriores e incluye nuevos criterios de éxito para abordar problemas de accesibilidad que han surgido desde el lanzamiento de WCAG 2.0. WCAG 2.1 también proporciona más orientación sobre la accesibilidad móvil, la accesibilidad para baja visión y las discapacidades cognitivas y de aprendizaje.

WCAG 2.2, la iteración más reciente de estas pautas, se publicó en 2023 y ofrece nueve nuevos criterios de éxito sobre WCAG 2.1. Proporciona orientación mejorada para abordar las necesidades de usuarios con discapacidades cognitivas o de aprendizaje, usuarios con baja visión y usuarios con discapacidades en dispositivos móviles. Es compatible con versiones anteriores de WCAG 2.1.

Comparación dentro de la rama

Una comparación dentro de la rama compara el escaneo de un commit con el escaneo del commit anterior que tiene resultados en la misma rama. Aparece en la vista de Commits y muestra lo que un commit específico introdujo o solucionó.