Conjuntos de reglas personalizados

Un conjunto de reglas personalizado es un archivo JSON generado que se pasa a axe.configure para controlar cómo axe prueba tu página. Puede modificar el modo en que se ejecutan las reglas existentes, como deshabilitarlas o cambiar su impacto, o puede usarse para crear reglas completamente nuevas.

Algunas de las cosas que puede hacer con conjuntos de reglas personalizados incluyen:

• Cambiar regla o impacto de la comprobación.
• Deshabilitar reglas.
• Crear nuevas reglas para probar la política de accesibilidad de su organización.
• Restringir las soluciones permitidas para los elementos. Por ejemplo, no permitir que el title atributo asigne a un <img> elemento un nombre accesible.
• Modificar el contraste mínimo en la regla de contraste de color.
• Actualizar qué roles y propiedades de ARIA son soportados.

El comando "ruleset" tiene el siguiente formato:

axe ruleset [options]

Opciones

-c, --custom <path>

Generar un conjunto de reglas personalizado desde un archivo changes.json en el directorio actual o desde la ruta especificada.

-d, --destino <path>

Directorio de salida para el archivo JSON del conjunto de reglas

-t, --tags <list>

Lista de etiquetas separadas por comas(https://github.com/dequelabs/axe-core/blob/develop/doc/API.md#axe-core-tags) que se utilizarán para filtrar el conjunto de reglas estándar

-f, --format [formato]

Formato de salida (js o json) para el archivo JSON del conjunto de reglas

-l, --log

Generar una lista de todas las reglas incluidas en los conjuntos de reglas generados.

-x, --disable-other-rules

Deshabilita todas las reglas no incluidas en la propiedad rules del archivo changes.json o en el directorio rules.

-a, --axe-source <path>

Ruta a un archivo de código fuente axe personalizado

--508 [nombre de archivo]

Generar configuración estándar para reglas de la Sección 508.

--en301549 [nombre de archivo]

Generar configuración estándar para reglas EN 301 549.

--ttv5 [nombre de archivo]

Generar configuración estándar para reglas de Trusted Tester v5.

--wcag2 [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.0.

--wcag21 [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.1.

--wcag22 [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.2.

--wcag2aaa [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.0 Nivel AAA.

--wcag21aaa [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.1 Nivel AAA.

--wcag22aaa [nombre de archivo]

Generar configuración estándar para las pautas WCAG 2.2 Nivel AAA.

--all [nombre de archivo]

Generar configuración estándar para todas las pautas (508, WCAG 2 y WCAG 2.1).

--only-changes

Genere solo los cambios y adiciones al conjunto de reglas y no la configuración completa.

Generando un conjunto de reglas personalizado

Para generar un conjunto de reglas personalizado, necesitará tener un archivo changes.json, ya sea en el directorio actual o en la ruta especificada por la opción --custom.

El archivo changes.json tiene el mismo formato que el objeto pasado a axe.configure. En el archivo se pueden especificar los cambios en las reglas y comprobaciones de axe actual, así como cualquier regla o comprobación nueva.

Por ejemplo, si quisiera cambiar el impacto de la regla valid-lang para que sea minor en lugar de serious, el archivo changes.json se vería así:

{
    "rules": [{
        "id": "valid-lang",
        "impact": "minor"
    }]
}

Uso de directorios de reglas y comprobaciones

Si lo desea, también puede separar las nuevas reglas y comprobaciones en sus propios directorios (denominados rules y checks respectivamente). Cada regla o verificación debe ser su propio archivo JSON en su directorio respectivo. Hacer esto no cambia la salida del archivo JSON generado, sino que es simplemente una forma conveniente de organizar múltiples reglas y verificaciones personalizadas en lugar de enumerarlas todas en el archivo changes.json .

Por ejemplo, para crear una nueva regla personalizada llamada h1-no-duplicate que verifique si hay más de un elemento <h1> en la página, podría tener la siguiente estructura de directorio:

directory
 ├ changes.json
 ├ rules
 │  └ h1-no-duplicate.json
 └ checks
    └ page-no-duplicate-h1.json

h1-no-duplicate.json El archivo de metadatos de la regla definiría la regla personalizada y qué comprobaciones utilizar:

{
    "id": "h1-no-duplicate",
    "selector": "h1:not([role]), [role=heading][aria-level=1]",
    "tags": ["cat.semantics", "best-practice"],
    "metadata": {
        "description": "Ensures the document has at most one h1 element",
        "help": "Document must not have more than one h1 element"
    },
    "all": [],
    "any": ["page-no-duplicate-h1"],
    "none": []
}

El archivo de metadatos de verificación definiría la verificación personalizada y qué método de page-no-duplicate-h1.json axe evaluate utilizar:

{
    "id": "page-no-duplicate-h1",
    "evaluate": "page-no-duplicate-evaluate",
    "after": "page-no-duplicate-after",
    "options": {
        "selector": "h1:not([role]), [role=heading][aria-level=1]"
    },
    "metadata": {
        "impact": "moderate",
        "messages": {
            "pass": "Document does not have more than one h1 element",
            "fail": "Document has more than one h1 element"
        }
    }
}

Por último, dado que no hay cambios en las reglas o controles actuales, el changes.json archivo sería un objeto vacío:

{}

Después de ejecutar el comando axe ruleset --custom , el archivo JSON generado se vería de la siguiente manera:

{
    "rules": [{
        "id": "h1-no-duplicate",
        "selector": "h1:not([role]), [role=heading][aria-level=1]",
        "tags": ["cat.semantics", "best-practice"],
        "metadata": {
            "description": "Ensures the document has at most one h1 element",
            "help": "Document must not have more than one h1 element"
        },
        "all": [],
        "any": ["page-no-duplicate-h1"],
        "none": []
    }],
    "checks": [{
        "id": "page-no-duplicate-h1",
        "evaluate": "page-no-duplicate-evaluate",
        "after": "page-no-duplicate-after",
        "options": {
            "selector": "h1:not([role]), [role=heading][aria-level=1]"
        },
        "metadata": {
            "impact": "moderate",
            "messages": {
                "pass": "Document does not have more than one h1 element",
                "fail": "Document has more than one h1 element"
            }
        }
    }]
}

Uso de un conjunto de reglas personalizado

Hay tres formas de configurar reglas personalizadas en axe DevTools.

• explícitamente: esto difiere entre paquetes, para CLI, use la bandera --custom .

• variable de entorno: si hay una AXE_RULESET_PATH variable de entorno establecida, axe DevTools la cargará como el conjunto de reglas predeterminado.

• archivo local: si hay un axe-ruleset.json en el directorio donde se ejecuta axe, se usará como el conjunto de reglas predeterminado.

Si no se especifica ninguno de estos, o si axe DevTools no puede cargar el archivo configurado, se utilizará en su lugar el wcag2 conjunto de reglas predeterminado.

Soporte

La creación de conjuntos de reglas personalizados requiere un conocimiento significativo de axe-core. Para obtener más detalles, consulte la documentación de la API de axe-core. Si desea ayuda para crear y mantener su conjunto de reglas personalizado, comuníquese con su representante de Deque.