Glosario del axe Developer Hub
Términos útiles para comprender axe Developer Hub
a11y
Abreviatura basada en números (o numerónimo, aunque no es un término común en español) para accesibilidad , con 11 (once) representa el número de caracteres entre la a primera y la y última en accesibilidad. Pronunciado aliado.
Clave API
Axe Developer Hub crea una clave API cada vez que creas un proyecto nuevo. La clave conecta las ejecuciones de pruebas y sus resultados con un proyecto determinado. Debe configurarse en el conjunto de pruebas para permitir que sus resultados se asocien con un proyecto específico.
axe Developer Hub
axe Developer Hub le permite crear nuevos proyectos de prueba y le muestra los resultados de sus ejecuciones de pruebas de accesibilidad. Puede filtrar los resultados por fecha, ID de sesión y gravedad. Puede supervisar sus resultados de accesibilidad y agruparlos por ID de sesión. Puedes crear tantos proyectos como necesites para monitorizar diferentes sitios web.
El paquete @axe-core/watcher
Integra ** el paquete @axe-core/watcher** en tu conjunto de pruebas de sitios web para analizar páginas web e informar los resultados al Hub para desarrolladores de axe, donde puedes verlos. El paquete @axe-core/watcher también escanea la confirmación y la rama de Git actuales y asocia las ejecuciones de prueba con la confirmación actual. El paquete @axe-core/watcher solo es compatible con Google Chrome al probar tu sitio web. Consulte Requisitos del sistema.
Prácticas recomendadas
Las mejores prácticas de Deque son técnicas probadas con el tiempo que brindan los resultados de accesibilidad deseados cuando faltan métodos formales específicos o estos son insuficientes. Si bien no están incluidos oficialmente 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 probada. Cabe señalar que el incumplimiento de las directrices de mejores prácticas de Deque no indica automáticamente un fracaso. Además, se requiere el juicio de expertos para considerar la idoneidad en el contexto de los objetivos de la aplicación, el sitio o la 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. Consulte Mejores prácticas para conocer las reglas que conforman el conjunto de reglas de mejores prácticas.
Plataforma de automatización del navegador
Una plataforma de automatización del navegador es un marco que se utiliza para automatizar las pruebas de su sitio web. Las plataformas incluyen Cypress, Playwright, Puppeteer, WebdriverIO y WebDriverJS. Para obtener más información, consulte
Prueba de componentes
Con Cypress o Playwright, puedes probar componentes individuales (como componentes React) de forma aislada. Compara esto con e2e Testing, que prueba toda la aplicación web en su implementación en el mundo real. Axe Developer Hub solo puede detectar problemas de accesibilidad en escenarios de extremo a extremo y no está diseñado para probar componentes de forma aislada. Consulte Pruebas e2e.
Anulación de la configuración
Una anulación de configuración le permite personalizar la configuración para ejecuciones de pruebas específicas a través de la propiedad [configurationOverrides] en sus configuraciones de prueba. **** (dh-api-reference#configurationoverrides-interface) Estas anulaciones deben cumplir con la configuración global de su organización y pueden incluir cambios en los estándares de accesibilidad, mejores prácticas, reglas experimentales y versiones de axe-core.
Duplicado
Un duplicado es el mismo problema de accesibilidad observado en el mismo nodo del modelo de objeto de documento (DOM) en varios estados de página. Si solucionas un problema con duplicados, todos sus duplicados desaparecerán porque son todos el mismo problema.
Pruebas de extremo a extremo
Las pruebas de extremo a extremo, o e2e, se refieren a probar la funcionalidad de toda la aplicación web probando su implementación en el mundo real. Con axe Developer Hub, puedes probar escenarios e2e para detectar problemas de accesibilidad, pero no puedes probar componentes individuales de forma aislada, como ofrecen Cypress y Playwright. Véase también Prueba de componentes.
Reglas experimentales
Todavía se están desarrollando y probando reglas experimentales para abordar nuevas tecnologías o aumentar la comprensión y la conciencia de las cuestiones de accesibilidad. No se debe confiar en estas reglas en entornos de producción porque aún están en desarrollo y están sujetas a falsos positivos. Con el tiempo, las reglas de este conjunto podrían convertirse en parte de los estándares de accesibilidad. Las reglas experimentales están deshabilitadas de forma predeterminada. Consulte [Reglas experimentales] (https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md#experimental-rules) para conocer las reglas que componen este conjunto de reglas en la última versión de axe-core.
Vaciar
La función flush escribe los resultados de la prueba en el servidor Deque y es necesaria para garantizar que axe Developer Hub registre los resultados. Debes llamar a la función flush en tu conjunto de pruebas.
Gitless
Gitless se refiere a utilizar el paquete @axe-core/watcher sin un repositorio Git. No es necesario utilizar un repositorio Git, pero un repositorio Git le permite asociar defectos de accesibilidad con cambios de código específicos, lo que ayuda a su resolución.
Configuración global
La configuración global es parte de axe Configuration que le permite configurar varias opciones en un solo lugar para compartirlas entre diferentes productos Deque. Su administrador puede permitir que los usuarios cambien determinadas configuraciones.
Impacto
A cada violación de accesibilidad se le asigna un nivel de impacto, categorizado en cuatro niveles de menor a mayor impacto: menor , moderado, 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 de forma predeterminada.
Los defectos con niveles de impacto graves o críticos presentan barreras significativas o insuperables para los usuarios con discapacidad, con la máxima responsabilidad legal. Si bien los problemas menores y moderados no son tan graves, siguen siendo cruciales para el cumplimiento y para abordar las necesidades de las personas con discapacidades.
Los cuatro niveles utilizados para categorizar el impacto de los problemas de accesibilidad son:
-
Leves: Problemas que afectan a usuarios con discapacidades menos que los problemas moderados pero que aun así requieren resolución para un cumplimiento total.
-
Moderado: Existen algunas barreras para los usuarios con discapacidades, pero no les impedirían acceder a contenidos o flujos básicos. Estos problemas pueden hacer que su organización sea vulnerable a acciones legales y deben solucionarse antes de lograr el cumplimiento total.
-
Grave: Los usuarios con discapacidades enfrentarán barreras importantes al interactuar con el sitio, lo que provocará frustración y dificultad para acceder al contenido relacionado. La remediación debe ser una alta prioridad para evitar acciones legales.
-
Crítico: A los usuarios con discapacidades se les impide completamente acceder o interactuar con una función de la página web, lo que hace que el contenido sea inaccesible y deja a su organización muy vulnerable a demandas judiciales. La solución de problemas críticos debe ser una máxima prioridad.
Modo manual
De forma predeterminada, axe Developer Hub analiza cada una de sus páginas web automáticamente y vuelve a analizar las páginas cada vez que detecta un nuevo estado de página. Puede deshabilitar este comportamiento automático estableciendo la propiedad autoAnalyze en el objeto de configuración axe en false. También puede anular el comportamiento del análisis automático utilizando el método stop . En cualquier caso, esto pone a Watcher en modo manual. En el modo manual, las páginas solo se analizan cuando se llama al método analyze .
Conjunto de pruebas modificado
Un ** conjunto de pruebas modificado** es un conjunto de pruebas que usted ha modificado de acuerdo con las instrucciones proporcionadas por axe Developer Hub cuando creó un nuevo proyecto. Modificar su conjunto de pruebas le permite agregar pruebas de accesibilidad a su conjunto de pruebas existente con cambios mínimos en el conjunto de pruebas en sí.
Estado de la página
El ** estado de la página** de una página web se refiere al estado de su modelo de objetos de documento (DOM) en un momento específico. Los estados de página son útiles para sitios web complejos con pantallas de inicio de sesión o UI dinámica como aplicaciones de página única (SPA). Ejemplos de estado DOM incluyen:
- La visibilidad de los elementos
- El contenido de los elementos
- El estado marcado de los botones de opción y casillas de verificación
El paquete @axe-core/watcher vuelve a escanear las páginas web cuando detecta cambios en el DOM y guarda un nuevo estado de página cada vez.
Proyecto
Un proyecto en Axe Developer Hub contiene resultados de accesibilidad, información de ejecución de pruebas y datos de Git (ramas y confirmaciones). La asociación entre esta información y el proyecto es a través de la clave API del proyecto. Crea y nombra un nuevo proyecto en axe Developer Hub, lo que crea una clave API que se utilizará con tus pruebas para identificar el proyecto.
ID de sesión
El ID de sesión se genera automáticamente como un UUID e identifica el inicio de sesión de un usuario en una máquina particular. Por lo general, la mayoría de los usuarios no necesitan cambiar el ID de la sesión. Sin embargo, si necesita distinguir entre diferentes ejecuciones de pruebas, puede utilizar diferentes ID de sesión. Debe utilizar un ID único global como un UUID para evitar posibles colisiones de ID de sesión en la misma organización.
SHA
Cuando creas una confirmación con Git, se crea un ID para identificar de forma única la confirmación. El identificador único se denomina SHA (llamado así por los algoritmos hash seguros, un grupo de funciones hash criptográficas).
Etiqueta
Una etiqueta agrupa reglas que pertenecen a una directriz de accesibilidad específica, como WCAG. Para obtener más información sobre las reglas y las etiquetas a las que pertenecen esas reglas, consulte Descripciones de reglas de axe-core
WCAG (en inglés)
WCAG, o Pautas de Accesibilidad al Contenido Web, son un conjunto de pautas desarrolladas por el Consorcio World Wide Web (W3C) para ayudar a que el contenido web sea más accesible para las personas con discapacidades. Estas directrices proporcionan un marco para crear sitios web y contenidos digitales accesibles que puedan ser utilizados por personas con una amplia gama de discapacidades.
Los tres niveles de conformidad de WCAG están definidos por un conjunto de criterios de éxito que describen elementos específicos del contenido web que deben cumplirse para lograr ese nivel de conformidad. El nivel de conformidad A es el nivel mínimo de conformidad, mientras que el nivel de conformidad AAA es el más estricto. El nivel de conformidad AA requiere la conformidad con los criterios de éxito tanto del nivel A como del nivel AA. Se requiere el cumplimiento de los tres niveles de criterios de éxito (A, AA y AAA) para cumplir 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 accesibilidad móvil, accesibilidad para personas con baja visión y 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 respecto de WCAG 2.1. Proporciona una orientación mejorada para abordar las necesidades de los 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.
Envoltorio
El envoltorio se refiere a modificar una plataforma de automatización del navegador (como Cypress) para llamar al código de prueba de accesibilidad (en el paquete @axe-core/watcher) cada vez que se llama a una función de la plataforma de automatización del navegador. El envoltorio le permite integrar pruebas de accesibilidad en sus suites de pruebas existentes con cambios mínimos en su código.