Uso de la acción GitHub axe DevTools Linter

Este artículo le muestra cómo usar la acción de GitHub Deque's axe DevTools Linter para verificar su código en busca de errores de accesibilidad al crear una solicitud de extracción de GitHub. Después de ejecutar la acción, la solicitud de extracción contendrá comentarios que muestran los errores de accesibilidad en los archivos confirmados.

Las siguientes secciones muestran los pasos para configurar esta acción de GitHub con su repositorio.

Step 1: Obtain an API Key (SaaS Only)

Para axe DevTools Linter SaaS, necesita obtener una clave API. Puede obtener una siguiendo los pasos en Cómo obtener una clave API de axe DevTools Linter SaaS, o puede usar una clave API existente desde la página de configuración de su cuenta de axe.(https://axe.deque.com/settings) Si tiene problemas para obtener una clave API, comuníquese con el servicio de asistencia de Deque.

Step 2: Create a Repository Secret for Your API Key (SaaS Only)

Si está usando axe DevTools Linter SaaS, necesita agregar tu clave API a los secretos de tu repositorio, lo que puede hacer yendo a la página de Configuración de tu repositorio en GitHub. Para obtener más información, consulte Creación de secretos cifrados para un repositorio en GitHub Docs.

Para el flujo de trabajo de ejemplo del siguiente paso, los secretos deberían llamarse:

• AXE_LINTER_API_KEY para la clave API

Paso 3: Crear el flujo de trabajo

A continuación, debe crear un flujo de trabajo para verificar si sus archivos tienen errores de accesibilidad. Puedes crear un archivo llamado axe-linter.yml en el directorio .github/workflows de tu repositorio.

Puedes crear este archivo en línea como un nuevo flujo de trabajo en la pestaña Acciones en la página web de tu repositorio (haz clic en configurar un flujo de trabajo tú mismo en la sección Comienza a usar GitHub Actions en la parte superior de la página Acciones ) o créalo localmente y haz commit al mismo en tu repositorio.

La acción axe-linter se invoca en el flujo de trabajo cuando se crea una solicitud de extracción (on: [pull_request]). El flujo de trabajo utiliza dos dependencias:

• actions/checkout@v4
• dequelabs/axe-linter-accion@v1

Las siguientes secciones muestran ejemplos de .github/workflows/axe-linter.yml que puedes usar para versiones SaaS o locales de axe DevTools Linter:

Para SaaS

La versión SaaS del flujo de trabajo incluye el parámetro api_key , pero no incluye el parámetro axe_linter_url :

name: Linting for accessibility issues

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: dequelabs/axe-linter-action@v1
        with:
          api_key: ${{ secrets.AXE_LINTER_API_KEY }}          github_token: ${{ secrets.GITHUB_TOKEN }}

Para en las instalaciones

La versión local del flujo de trabajo incluye el parámetro axe_linter_url , pero no incluye el parámetro api_key :

name: Linting for accessibility issues

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: dequelabs/axe-linter-action@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          axe_linter_url: $AXE_LINTER_URL

El valor de axe_linter_url se lee en este ejemplo desde el entorno de shell como AXE_LINTER_URL.

Para la versión en las instalaciones de axe DevTools Linter, no necesita una clave API, pero su instancia de axe DevTools Linter debe ser accesible a los flujos de trabajo de GitHub a través de una conexión de red.

Parámetros de acción de GitHub

La dequelabs/axe-linter-action utiliza los siguientes parámetros (especificados en los ejemplos anteriores en la cláusula with ):

Resultados del flujo de trabajo

La siguiente captura de pantalla muestra el resultado de crear una solicitud de extracción con un archivo que tiene un error de accesibilidad. El archivo, bad-file.md, contiene niveles de encabezado que van desde el nivel de encabezado 1 hasta el nivel de encabezado 3, omitiendo el nivel 2, lo cual es un error de accesibilidad.

Solución de problemas

La depuración de problemas con acciones de GitHub puede ser un desafío porque los mensajes de error a menudo no representan con precisión el problema subyacente. Esta sección contiene algunos ejemplos de errores que podrías ver.

Incorrectly Named Secret (SaaS Only)

Si el nombre que le da a su clave secreta de API no coincide con el nombre en el flujo de trabajo, puede recibir errores sobre un comando faltante en lugar de un error de que la clave no está definida:

... line 41: Missing: command not found

Errores de permisos

Hay muchos lugares con acciones de GitHub donde los permisos pueden ser incorrectos. Por ejemplo, si hace referencia a un repositorio que no es público con una cláusula usa , a menudo recibirá el error que indica que no se encontró el repositorio en lugar de que no tiene acceso a él:

fatal: repository 'name' not found

Archivos comprobados por la acción

Los archivos con estas extensiones se comprobarán para detectar errores de accesibilidad:

• .js
• .jsx
• .tsx
• .html
• .vue
• .md
• .markdown

Próximos pasos

Para obtener información sobre las reglas que utiliza axe DevTools Linter para verificar su código, consulte Reglas de accesibilidad. Si desea obtener más información sobre cómo evitar que los archivos con errores de accesibilidad se confirmen en Git, consulte Cómo usar un gancho de preconfirmación de Git.