Mapeo de conformidad con WCAG

Cómo se relacionan los resultados de reglas individuales con un Criterio de Éxito (SC) de WCAG, y qué puede y no puede decirte surea11y sobre la conformidad general.

Las tres capas

1. Reglas atómicas (checksResults[]): una decisión normativa cada una, por ejemplo "¿tiene este <img> un atributo alt?". Ver el catálogo de reglas para las 132.
2. Facetas: un SC de WCAG suele ser más grande de lo que una sola regla puede decidir de forma determinista. Internamente, cada SC se divide en "facetas" nombradas (por ejemplo, 1.1.1 Non-text Content tiene facetas como img-alt-attr-present, text-alternative-quality, decorative-null) registradas en src/coverage/wcag-facets.js, cada una marcada como full (una regla la decide con alta confianza), partial (una regla decide parte de ella; ver las notas de alcance de cada regla) o manual (no existe ninguna heurística automatizada segura). Ejecuta npm run coverage para regenerar coverage/coverage-report.md, el desglose de facetas por SC.
3. Reglas compuestas (resultado agregado por SC de WCAG) (rulesResults[]): un agregado generado de cada regla atómica asociada a un SC, que da un único veredicto pass/fail/cantTell/notApplicable por SC en lugar de tener que combinar tú mismo docenas de resultados atómicos. Ver la lista completa (por ejemplo, wcag-1.1.1-non-text-content agrupa 21 reglas atómicas).

Cómo se calcula el resultado de un compuesto

Precedencia determinista, evaluada sobre los contribuyentes atómicos de ese compuesto:

Esto significa: un compuesto en pass es un "todas las comprobaciones automatizadas aplicables a este SC salieron limpias" real y determinista, pero no es, por sí solo, una declaración de conformidad WCAG. Si alguna faceta de ese SC no tiene ninguna cobertura automatizada (ver coverage-report.md), un compuesto en pass guarda silencio sobre esa faceta, no está afirmando que esté bien. Verifica la tabla de facetas antes de tratar un compuesto en pass como "SC totalmente verificado".

El array data.details.contributors de un compuesto (ver el esquema de salida) enumera cada regla atómica y su resultado individual: úsalo para ver exactamente qué faceta o facetas provocaron un fail/cantTell, en lugar de tratar el compuesto como una caja negra.

Apuntar a un nivel de conformidad (A / AA / AAA)

Pasa runOnly.tags (o engineOptions.tags.include) con las etiquetas de nivel que quieras:

// WCAG 2.0 A y AA. Ambas etiquetas son necesarias: no son acumulativas.
runDomRulesInPage(url, null, {}, { tags: ['wcag2a', 'wcag2aa'] });

Las etiquetas de nivel no se anidan, y esto es lo más fácil de entender mal aquí. Una regla lleva una etiqueta de nivel por cada Criterio de Éxito al que se asocia, y nada más: una regla asociada solo a un criterio AA lleva la etiqueta wcag2aa y no wcag2a. Pedir { tags: ['wcag2aa'] } por sí solo, por tanto, ejecuta las 10 reglas asociadas a un criterio AA de la versión 2.0, no las aproximadamente 100 que forman un objetivo A + AA. Enumera cada nivel que quieras.

Lo mismo aplica entre versiones de WCAG (un criterio introducido en 2.1 o 2.2 lleva solo su propia etiqueta de origen), así que un objetivo de conformidad completo es una unión de conjuntos de etiquetas. Ver la guía de opciones del motor para los conjuntos ya preparados por versión, incluido el único criterio que WCAG 2.2 eliminó en lugar de añadir.

El criterio eliminado se maneja automáticamente. Cada ejecución resuelve una versión de WCAG objetivo (engineOptions.wcagVersion, si no, lo que impliquen tus etiquetas de versión, si no, 2.2) y la devuelve como engine.wcagVersion. Bajo un objetivo 2.2, una regla asociada solo al SC 4.1.1 Parsing no puede devolver fail: se ejecuta, informa de sus ocurrencias, y vuelve como cantTell con un campo wcagVersionScope que explica la coerción. Así, un análisis por defecto nunca bloquea por un criterio que WCAG 2.2 no contiene, y un análisis 2.0/2.1 sigue obteniendo un veredicto real para el 4.1.1.

Los compuestos, a diferencia de las reglas atómicas, sí se filtran de forma acumulativa. El ejecutor lee el nivel más alto nombrado en tags y descarta todo compuesto por encima de él, así que pedir ['wcag2a', 'wcag2aa'] no devuelve ninguna entrada en rulesResults para un SC exclusivo de AAA. Eso es inferTargetLevelFromRunOnly/isAllowedByTargetLevel en src/core/dom-runner.js si necesitas la precedencia exacta.

Omite tags por completo (el valor por defecto) y se ejecuta cada regla en cada nivel, sin ninguna supresión de compuestos.

Lo que este motor no puede decirte

Ninguna herramienta automatizada, esta incluida, puede certificar la conformidad WCAG completa. Esa no es una limitación específica de surea11y; es inherente a WCAG en sí; una fracción importante de los Criterios de Éxito requiere criterio humano (¿es este texto alternativo exacto, y no solo presente?; ¿es este mensaje de error comprensible?) o pruebas dinámicas que la arquitectura de análisis estático del DOM de este motor no puede realizar en absoluto (detección de trampas de teclado, disposición y reflujo real con zoom). Ver las limitaciones conocidas para la lista completa y explícita de qué queda fuera de alcance y por qué.

Lo que surea11y sí puede darte, con honestidad:

• Cada fail es una violación normativa real, determinista, bajo la versión que elegiste como objetivo, nunca una suposición.
• Cada cantTell es una señal explícita para revisión humana, no una incertidumbre silenciada.
• La tabla de cobertura de facetas te dice exactamente qué partes de qué SC no tienen ninguna cobertura automatizada, para que sepas dónde un pass guarda silencio en lugar de ser exhaustivo.

Un compuesto en pass en cada SC de tu nivel objetivo significa: cada comprobación automatizable para ese nivel salió limpia. Es el subconjunto automatizable de la conformidad, declarado con precisión, no un sustituto de la revisión manual que la propia WCAG exige.