Elegir la Configuración Correcta de Axe DevTools Linter

Axe DevTools Linter se puede utilizar de muchas maneras, y la combinación correcta depende de cómo tu equipo escribe, revisa y publica el código. Esta guía abarca las decisiones principales para que puedas elegir una configuración que se ajuste a tus circunstancias. La mayoría de los equipos combinan varias de estas opciones en lugar de elegir solo una.

Las decisiones se dividen en cuatro áreas:

1. Dónde se realiza el análisis (si los archivos se analizan localmente o en un servidor, y qué modelo de implementación aloja ese servidor)
2. Dónde ocurre el linting en tu flujo de trabajo (IDE, gancho pre-commit, CI/CD)
3. Si necesitas configurar bibliotecas de componentes
4. Cuándo añadir otras integraciones como SonarQube

1. Elegir Dónde se Realiza el Análisis

Aquí hay dos decisiones relacionadas: si tus archivos se analizan en tu propia máquina o se envían a un servidor y, si se involucra un servidor, qué tipo de servidor lo aloja.

Linting Local o Basado en Servidor

Dónde se analizan tus archivos, y si su contenido sale de tu máquina, depende de la integración. Las tres familias de integraciones se comportan de manera diferente:

• Las integraciones IDE siempre realizan el linting localmente. La Extensión de VS Code y el Plugin de JetBrains analizan archivos en tu propia máquina con un componente integrado, por lo que el contenido de los archivos nunca sale de tu computadora. No requieren clave API ni licencia para hacer linting.
• El Conector puede realizar el linting de ambas maneras. Por defecto, el Conector envía archivos a un servidor de Axe DevTools Linter, pero su opción --local los analiza en tu máquina, así que su contenido nunca la abandona. Deque recomienda realizar el linting localmente en la mayoría de los casos: es significativamente más rápido y menos propenso a problemas de red, especialmente cuando se realiza el linting de un gran número de archivos. Sea cual sea la forma en que realices el linting, el Conector se autentica, según lo descrito en autenticación del Conector a continuación.
• La Acción de GitHub siempre se basa en el servidor. La Acción de GitHub envía los archivos modificados a un servidor de Axe DevTools Linter para su análisis. No tiene modo local, así que esta opción siempre envía el contenido de los archivos al servidor.

Autenticación del Conector

Cuando utilices el Conector, te autenticarás con una de dos credenciales, ya sea que realices el linting localmente o en un servidor:

• Clave API (la opción de --api-key): Administra las claves API por ti mismo como parte de tu Cuenta de Axe. El Conector contacta un servidor remoto para validar la clave y reportar el uso (las líneas de código analizadas). Esto ocurre incluso cuando realizas el linting localmente.
• Clave de licencia (la opción de --license-key): Solicitas una clave de licencia de Mesa de Ayuda de Deque. Se autentica sin actividad de red y no rastrea el uso, lo que la convierte en la elección adecuada para redes aisladas o entornos con reglas estrictas de salida. Solo está disponible con el linting local.

Esto le da al Conector tres modos de funcionamiento:

Las integraciones de IDE no necesitan credenciales para hacer el lint. La GitHub Action se autentica con una clave API; su guía de configuración cubre el flujo de trabajo tanto para servidores SaaS como on-premises.

Modelo de Despliegue de Servidor

Si haces lint contra un servidor, o te autenticas con una clave API mientras haces lint localmente, también eliges qué tipo de servidor aloja Axe DevTools Linter. Esto afecta el esfuerzo de configuración, si tus archivos salen de tu red y cómo te autenticas.

Elige SaaS para el inicio más rápido y sin infraestructura que mantener. Elige on-premises cuando la política requiera que el código fuente permanezca dentro de tu red, o cuando desees control total sobre el servidor. Elige nube privada cuando quieras una instancia dedicada gestionada por Deque sin tener que ejecutar el servidor tú mismo.

2. Elige Dónde Ocurre el Linting en Tu Flujo de Trabajo

La retroalimentación sobre accesibilidad es más útil temprano y frecuentemente. Las integraciones a continuación se aplican en diferentes puntos del ciclo de vida del desarrollo, y funcionan bien juntas: detecta problemas mientras escribes, nuevamente antes de un commit y una vez más en la solicitud de extracción.

Una aproximación común y escalonada es:

1. Extensión del IDE para que los desarrolladores vean los problemas inmediatamente mientras escriben código.
2. Hook de pre-commit o Acción de GitHub como control para que los problemas se detecten antes o durante la revisión de código.
3. Conector en CI/CD para imponer verificaciones en toda la base de código y alimentar otros sistemas.

No es necesario adoptar las tres capas de una vez. Los equipos a menudo comienzan con la extensión del IDE y luego añaden una comprobación de pull request una vez que están listos para aplicar estándares en todo el equipo.

3. Decidir si Configurar Bibliotecas de Componentes

Por defecto, Axe DevTools Linter verifica los elementos HTML estándar y el marcado del framework. Si tu código utiliza componentes personalizados (por ejemplo, un <custom-image> que renderiza un <img>), el linter no puede verificar su accesibilidad hasta que le indiques cómo cada componente se mapea a un elemento estándar.

Deberías configurar el linting de componentes si:

• Tu base de código se basa en un sistema de diseño o una biblioteca de componentes personalizados, y
• Quieres que se señalen los problemas de accesibilidad dentro de esos componentes.

Hay dos caminos:

• Bibliotecas de componentes preconfiguradas: Si usas Cauldron React, Material UI (@mui/material), o React Native, el soporte está integrado. Ver Bibliotecas de Componentes Preconfiguradas.
• Mapeos personalizados: Para tus propios componentes, crea mapeos en tu configuración. Consulta Linting de Componentes Personalizados para obtener una visión general, luego sigue la guía de VS Code y JetBrains o el punto de acceso REST.

Las opciones de configuración se comparten en todas las integraciones del IDE, el Conector y la API REST, y están documentadas en Configuración de Axe DevTools Linter.

4. Decidir Cuándo Añadir Otras Integraciones

Las integraciones en paso 2 cubren las necesidades de la mayoría de los equipos. Considera las siguientes integraciones adicionales cuando coincidan con las herramientas que ya utilizas:

Estas integraciones se basan todas en el Conector, que produce los resultados de linting que cada sistema consume. La regla general: utiliza otra integración cuando permita que los hallazgos de accesibilidad se muestren en una herramienta en la que tu equipo ya confía, en lugar de añadir una nueva herramienta por el mero hecho de hacerlo.

Poniéndolo Todo Junto

Una configuración típica para un equipo que utiliza SaaS podría ser:

• El Extensión de VS Code (o Plugin de JetBrains) para cada desarrollador, para recibir feedback mientras codifican.
• El Acción de GitHub en las pull requests, para que los problemas de accesibilidad sean visibles durante la revisión de código.
• Mapeos de componentes personalizados si el equipo utiliza un sistema de diseño.
• SonarQube integración solo si el equipo ya centraliza la calidad del código allí.

Un equipo con requisitos más estrictos de manejo de datos podría reemplazar SaaS con la implementación local y usar el Conector con --local en su pipeline de CI/CD para que el código fuente nunca salga de su red.

Si no está seguro de qué combinación se adapta a sus circunstancias, contacte con centro de ayuda de Deque.