Conformidad

Un análisis limpio no es, por sí solo, una declaración de conformidad con WCAG. Pretender lo contrario es exactamente el tipo de exceso que este motor se niega a cometer. Esta sección cubre cómo los resultados de reglas individuales realmente se agregan en un veredicto de Criterio de Éxito, qué cubre honestamente ese veredicto y qué no, y cómo condicionar un pipeline de CI real a violaciones conocidas y ya revisadas en lugar de bloquear cada compilación hasta que todo esté arreglado de una vez.

Mapeo de conformidad con WCAG

Mira exactamente cómo encajan entre sí las reglas atómicas, las facetas de cobertura y las reglas compuestas de resultado agregado por SC de WCAG, y por qué un criterio cuyas comprobaciones salieron todas limpias queda en cantTell, comprobado en parte, en lugar de un vago "parece estar bien": un compuesto dice qué partes se comprobaron y deja el resto a una persona. Un análisis que nombra unas pocas comprobaciones en lugar de un objetivo sigue informando de los criterios a los que pertenecen, e indica cuáles comprobó solo en parte. Apunta a un nivel de conformidad (A, AA o AAA) en cualquier versión de WCAG con un único conjunto de etiquetas o un perfil con nombre, asocia cada resultado a la cláusula de EN 301 549 que reformula su criterio cuando ese es el estándar con el que informas, y obtén una respuesta directa a la pregunta que de verdad importa: qué puede decirte este tipo de resultado automatizado, y dónde se detiene. Ver Mapeo de conformidad con WCAG.

Procedimientos de prueba

Un análisis es la mitad de una evaluación; la otra mitad es una persona comprobando lo que las reglas no pueden decidir. Core da también esa mitad: para cada criterio que evalúan sus reglas, un procedimiento por faceta, con los pasos, las herramientas que necesita y qué cumple y qué falla, en cinco idiomas. Léelos como datos, o como una página de referencia o una hoja de trabajo que registra cada resultado y los agrega por criterio, sin análisis o junto a uno, para que una auditoría y una ejecución de CI trabajen con el mismo texto. Ver Procedimientos de prueba.

Baseline / allowlist

No dejes que un primer análisis de un sitio existente e imperfecto bloquee cada compilación futura: registra una sola vez lo que ya se conoce, y condiciona la CI solo a violaciones genuinamente nuevas. Es la diferencia entre "no podemos publicar nada hasta que esto sea perfecto" y "podemos detectar regresiones a partir de hoy", y es lo que de verdad hace que un equipo active la puerta de control. También puede aceptar los hallazgos que probablemente fallan, un baseline cubre un análisis de varios perfiles, y un baseline escrito antes de actualizar sigue coincidiendo durante una versión menor cuando el código de motivo de un hallazgo se divide o se le asigna por primera vez. Ver Baseline / allowlist.