El Remediation Evidence Package

El Remediation Evidence Package tiene siete secciones, siempre en el mismo orden. Validiscan lo elabora a partir del escaneo de referencia o de un escaneo completo posterior de su tienda, del escaneo de verificación realizado tras las correcciones, si lo hay, y de los resultados de las revisiones manuales. La estructura siguiente usa los títulos de las secciones exactamente como figuran en el paquete.

Cada paquete está redactado en un solo idioma, que se elige al generarlo: inglés, alemán, danés, francés o español.

Para cada criterio de conformidad de las WCAG 2.1 AA y de las WCAG 2.2 AA, el paquete indica su conformidad tal como se evaluó en las páginas y fechas que enumera: «Cumple», «Cumple parcialmente», «No cumple», «No aplicable» o «No evaluado». No certifica la tienda. En la primera sección, su declaración de alcance empieza con esta frase: «La conformidad con los criterios de conformidad de las WCAG 2.1 AA y de las WCAG 2.2 AA, tal como se evaluaron en las páginas y fechas indicadas.»

El mismo recuadro dice: «Este paquete aporta evidencias de una evaluación y de trabajos de corrección. No es un certificado y no afirma el cumplimiento de ninguna obligación legal.»

Las dos frases aparecen también, en inglés, en el archivo README del zip.

Un hallazgo corregido se considera verificado cuando el escaneo de verificación del paquete carga todas las páginas en las que aparecía el hallazgo y ya no lo encuentra. Entonces su estado pasa de Corregido a Verificado en el momento en que se emite el paquete. Nadie asigna a mano el estado «Verificado».

Un hallazgo está corregido cuando se ha entregado una corrección para él y un escaneo posterior que ha cargado todas las páginas en las que aparecía ya no lo encuentra. El paquete verifica un hallazgo corregido cuando se dan tres condiciones:

1. El hallazgo tenía apariciones en el escaneo completo a partir del cual se elabora el paquete.
2. El escaneo de verificación no encontró ninguna.
3. El escaneo de verificación cargó todas las páginas en las que estaba el hallazgo, sin ningún error en ninguno de los tamaños de pantalla.

Cada hallazgo verificado lleva la nota «Verificado por este paquete» en la sección de hallazgos. Si el paquete no puede verificar así un hallazgo corregido, este sigue como corregido y figura como pendiente de verificación, con la recomendación de ejecutar un escaneo de verificación. Un paquete elaborado sin escaneo de verificación no verifica ninguna corrección, y así lo indican sus limitaciones.

El progreso de las correcciones es la parte del trabajo que está hecha, ponderada según cuánto afecta cada problema a los clientes. Es la única cifra global del paquete: no existe ningún porcentaje de cumplimiento.

Cada hallazgo cuenta con el peso de su impacto. El progreso de las correcciones es la suma de los pesos de los hallazgos corregidos, verificados o resueltos externamente, dividida por la suma de los pesos de todos los hallazgos. Los hallazgos marcados como falso positivo o como «No se corregirá» y los hallazgos de buena práctica quedan fuera de las dos sumas. El paquete presenta la fórmula así: «Σ peso(impacto) de los hallazgos corregidos, verificados o resueltos externamente ÷ Σ peso(impacto) de todos los hallazgos, sin contar los falsos positivos, los hallazgos que no se corregirán ni los de buenas prácticas.»

El progreso se cuenta por hallazgo, no por aparición: una etiqueta que falta y se repite en muchas páginas de producto es un solo hallazgo con una sola corrección. Un hallazgo crítico pesa más que uno menor, de modo que corregir un hallazgo crítico hace avanzar más la cifra que corregir uno menor. Junto al porcentaje, el paquete indica cuántos hallazgos ponderados están hechos y cuál es el total, para que la cifra pueda comprobarse a mano. El portal del cliente muestra la misma cifra, con su propia explicación de cómo se calcula.

Hay dos puntos que se pasan por alto con facilidad. Un hallazgo corregido cuenta como hecho antes de que se verifique, mientras que en las tablas de conformidad una corrección pendiente de verificación impide que su criterio cuente como «Cumple». Y un hallazgo marcado como «No se corregirá» queda fuera del progreso de las correcciones, pero sigue contando como incumplimiento en la conformidad, porque una barrera que permanece sigue siendo una barrera.

El paquete evalúa cada criterio de conformidad una sola vez e informa de los resultados con respecto tanto a las WCAG 2.1 AA como a las WCAG 2.2 AA. Las WCAG 2.2 AA son el objetivo de cada hallazgo y de cada corrección. Las WCAG 2.1 AA son el nivel que adopta la norma EN 301 549 V3.2.1 en sus requisitos para el contenido web. En los niveles A y AA, las WCAG 2.2 añaden seis criterios de conformidad a las WCAG 2.1 y eliminan uno, el 4.1.1 Parsing, por lo que las dos tablas difieren.

A fecha de 6 de octubre de 2026:

• La norma EN 301 549 V3.2.1 es la versión cuya referencia está publicada en el Diario Oficial de la UE, en el marco de la Directiva sobre accesibilidad web (Directiva (UE) 2016/2102), mediante la Decisión de Ejecución (UE) 2021/1339 de la Comisión.
• ETSI publicó la norma EN 301 549 V4.1.1 en septiembre de 2026. Según AccessibleEU, una iniciativa de la Comisión Europea, adopta las WCAG 2.2. Validiscan no encontró ninguna referencia a la V4.1.1 en el Diario Oficial.

Cada paquete registra las normas, con sus versiones y su situación, tal como estaban cuando se elaboró. Un cambio posterior en la situación de una norma no reescribe lo que dice un paquete ya emitido. Qué norma y qué ley se aplican a su tienda es una cuestión jurídica. La guía sobre la Ley Europea de Accesibilidad para tiendas online aborda este punto.

El zip contiene estas entradas, en este orden:

1. README.txt: qué es el paquete, qué contiene cada archivo y cómo verificarlo, en inglés.
2. El informe en PDF.
3. El documento de Word.
4. El archivo de datos JSON.
5. schema.json: el esquema JSON que sigue el archivo de datos.
6. assets/: las capturas de pantalla y los archivos de evidencia de las revisiones manuales a los que remite el informe.
7. SHA256SUMS: la suma de comprobación SHA-256 de cada uno de los demás archivos del zip.

Si falta una captura de pantalla o un archivo de evidencia cuando se elabora el paquete, se deja fuera del zip y el README lo indica bajo el encabezado FILES NOT INCLUDED. En lugar de una captura que falta, el informe muestra una descripción en texto.

Cada archivo del paquete tiene una suma de comprobación SHA-256: una huella digital que cambia si cambia un solo byte del archivo. El paquete usa sumas de comprobación en tres lugares.

• Cada archivo. El PDF, el documento de Word, el archivo JSON y el zip tienen cada uno su propio SHA-256, que se registra al elaborar el paquete y se muestra junto a cada descarga en el portal del cliente.
• Dentro del zip. El archivo SHA256SUMS enumera el SHA-256 de cada uno de los demás archivos del zip. Un zip no puede contener su propia suma de comprobación, así que el propio zip se comprueba con la suma que se muestra junto a su descarga.
• Los datos. La primera sección del paquete indica el SHA-256 del contenido del archivo JSON. Se calcula sobre el JSON canónico de ese archivo (RFC 8785, el JSON Canonicalization Scheme), sin ese único campo. El JSON canónico no depende de los espacios en blanco ni del orden de las claves, por lo que cualquiera que tenga el archivo JSON puede calcular el mismo valor.

Para comprobar los archivos descomprimidos, abra una terminal en su carpeta. En Linux, ejecute:

sha256sum -c SHA256SUMS

En macOS, ejecute:

shasum -a 256 -c SHA256SUMS

Cada línea debe terminar en «OK». En Windows PowerShell, ejecute este comando para cada archivo y compare el resultado con la línea de ese archivo en SHA256SUMS:

Get-FileHash -Algorithm SHA256

Una suma de comprobación demuestra que un archivo es exactamente el que se registró cuando se elaboró el paquete. No demuestra quién creó el archivo: el paquete no lleva firma digital ni sello de tiempo de un tercero.

El archivo de datos JSON sigue un JSON Schema publicado (draft 2020-12): el esquema JSON del paquete. El mismo esquema se incluye en cada zip como schema.json, de modo que un paquete puede comprobarse sin este sitio web. Cualquier validador de JSON Schema que admita el draft 2020-12 puede validar un archivo de datos con él.

El esquema es estricto: una clave que no conoce hace fallar la validación, salvo en un campo abierto para las versiones de otras herramientas. Validiscan elabora un paquete solo a partir de datos que superan la validación del esquema y coinciden con el SHA-256 registrado en su primera sección. El esquema está en la versión 1. Un cambio que rechazaría un programa preparado para una versión anterior recibe un número de versión nuevo, y un paquete emitido sigue siendo legible en su versión.

Los paquetes se numeran por tienda: versión 1, versión 2 y así sucesivamente. Cada paquete que Validiscan elabora para su tienda, a partir de los escaneos y en el idioma elegido para él, es la versión siguiente. Solo un paquete listo llega al portal del cliente.

Una vez que un paquete está listo, la base de datos rechaza cualquier cambio en las rutas de sus archivos, en sus sumas de comprobación, en su versión, en su idioma, en su registro de las normas o en su fecha de generación. Como las sumas de comprobación quedan fijadas, un archivo modificado después ya no coincidiría con la suma registrada para él.

El paquete es un registro de lo que se probó, se encontró, se cambió y se verificó. No afirma nada más.

• No es un certificado. Aporta evidencias de una evaluación y de trabajos de corrección.
• No afirma el cumplimiento legal. Si su tienda se ajusta a la EAA, a la BFSG o a otra ley es una valoración jurídica que corresponde a usted y a su abogado. La situación de cumplimiento del borrador de declaración es un borrador, redactado con la formulación del modelo de la UE, para esa revisión.
• No prueba todo de forma automática. Las pruebas automáticas solo detectan una parte de las barreras de accesibilidad. Los criterios que tienen un punto en la lista de comprobación manual se revisan a mano, o se marcan como «No evaluado» hasta que se revisan. Un criterio sin punto en la lista, como el 1.1.1 Non-text Content, cuenta como «Cumple» basándose solo en las pruebas automáticas, aunque una regla no puede juzgar si una alternativa textual describe su imagen. Las páginas se evalúan por muestreo según el tipo de página, no una por una.
• Describe la tienda en las fechas de los escaneos. Los cambios posteriores en el tema, las apps o el contenido no están cubiertos. La protección contra regresiones los comprueba de forma periódica.
• No afirma conformidad con PDF/UA. El PDF está etiquetado, con encabezados reales y alternativas textuales, pero Validiscan no afirma que sea conforme con PDF/UA.
• El borrador de declaración no está listo para publicarse. Necesita los datos de su organización y la revisión de su asesor jurídico.

En el portal figura cada versión del paquete, de la más reciente a la más antigua, con la fecha de emisión. De cada versión puede descargar el informe en PDF, el documento de Word, el archivo de datos JSON y el archivo zip. Cada archivo se muestra con su suma de comprobación SHA-256, que puede copiar. Cada enlace de descarga se crea al hacer clic en él y caduca al cabo de un minuto; no se guarda ningún enlace de descarga. Si el sitio de su tienda se archiva más adelante y deja de aparecer en el portal, sus paquetes siguen en la lista y se pueden descargar. El portal también tiene una página con el borrador de declaración de accesibilidad de su último paquete, que puede copiar o descargar como archivo HTML.

Conserve todas las versiones para su documentación. El Remediation Evidence Package forma parte de todos los proyectos; la página sobre cómo se desarrolla un proyecto enumera qué más incluye un proyecto.