Cómo funciona la corrección de accesibilidad web, paso a paso

Antes de empezar, Validiscan necesita tres respuestas: su permiso para escanear, cómo deben llegar los cambios a su código y si la IA puede redactar algunos de ellos.

• Permiso para un escaneo completo. Un escaneo completo va más allá de la revisión gratuita: añade un producto al carrito y abre el primer paso del proceso de pago. Validiscan solo lo ejecuta después de que el propietario de la tienda lo haya autorizado por escrito. Validiscan registra el permiso en su sistema, con la hora y el nombre de la persona de Validiscan que lo registró. Sin ese registro, no se inicia ningún escaneo completo.
• Acceso a su código. De una de estas tres formas, que se explican más abajo: acceso al repositorio de GitHub que contiene su tema, una contraseña de Theme Access de su tienda de Shopify o ningún acceso a sus sistemas, en cuyo caso su desarrollador sube una copia de los archivos de su tema y los cambios le llegan como un paquete de parches. Esa es también la vía cuando su tema se guarda en un lugar distinto de GitHub, por ejemplo en GitLab o Bitbucket.
• Su respuesta sobre la redacción con IA. La IA solo se usa para redactar correcciones de nivel ASSISTED, y solo si usted lo acepta. Está desactivada hasta que lo haga. Cómo trata Validiscan sus datos

El escaneo de referencia comprueba las páginas de su tienda según las WCAG 2.2 AA y enumera cada fallo que encuentra, con lo que supone para sus clientes.

El escaneo carga una muestra de cada tipo de página de su tienda, entre ellos la página de inicio, las listas de productos, las páginas de producto, el carrito, el primer paso del proceso de pago, los resultados de búsqueda, la página de inicio de sesión, la página de contacto y las páginas legales. El número de páginas de cada tipo que carga, y el límite de páginas, se fijan para cada tienda; por defecto, el límite es de 150 páginas de muestra, y a ellas pueden sumarse los resultados de búsqueda, la página de inicio de sesión, la página de contacto, las páginas legales, el carrito y el primer paso del proceso de pago. Por defecto, cada página se carga en tamaño de escritorio (1440 × 900 píxeles) y de móvil (390 × 844 píxeles). Para llegar al carrito y al proceso de pago, el escaneo añade un producto al carrito y abre el primer paso del proceso de pago. Nunca completa una compra y nunca introduce datos de pago.

El escáner ejecuta 102 reglas automáticas: reglas de axe-core y comprobaciones propias de Validiscan para problemas típicos de las tiendas, como los banners de cookies, los carruseles, los formularios del proceso de pago y las actualizaciones de precios. Un escaneo no puede demostrarlo todo. Validiscan también recorre una lista de comprobación de 35 revisiones manuales, que abarca todos los criterios de conformidad de las WCAG que ninguna regla comprueba, y registra cada una como superada, no superada o no aplicable, con notas.

Antes de entregar nada, Validiscan repasa los hallazgos. Este paso se llama triaje. El mismo fallo en muchas páginas, como un botón sin nombre en la cabecera, es un solo hallazgo, con el recuento de las páginas y de los elementos en los que aparece. Un hallazgo que resulta no ser un fallo se marca como falso positivo, con una justificación por escrito. El Remediation Evidence Package los enumera como hallazgos excluidos.

Validiscan revisa cada cambio antes de entregarlo: el diff, el resultado de la validación automática y la explicación de qué ha cambiado y por qué. La validación comprueba si cada archivo Liquid, Twig, PHP, HTML, XML, JavaScript o JSON modificado tiene errores, con un analizador sintáctico o una comprobación de sintaxis adecuados a su tipo, y somete cada archivo CSS, SCSS o LESS modificado a una comprobación de estructura que busca una llave, una cadena o un comentario sin cerrar, sin compilar el archivo; ninguna de estas comprobaciones ejecuta el código de su tema. Solo se entregan los cambios que han superado la validación y que Validiscan ha aprobado. Un cambio rechazado recibe un motivo por escrito y no se entrega.

Después, su desarrollador vuelve a revisar el cambio, como cualquier otro pull request o parche, o usted previsualiza la copia del tema en Shopify. La lista de comprobación de cada pull request pide a su desarrollador que pruebe la rama fuera de la tienda en producción, que compruebe las páginas afectadas, que maneje los elementos modificados solo con el teclado y, cuando pueda, con un lector de pantalla.

En Validiscan, la persona que revisa los cambios es William Quaade Rasmussen, que dirige la empresa en solitario. Como los cambios están en su código y el paquete es su archivo, después nada en su tienda depende de Validiscan; la protección contra regresiones se puede cancelar para el final de cualquier mes. Acerca de Validiscan

Una vez que los cambios están en producción en su tienda, un escaneo de verificación comprueba que funcionan. Abarca los tipos de página a los que afectan los cambios y todas las páginas en las que se vio por última vez un hallazgo con un cambio entregado. Un hallazgo con un cambio entregado que el escaneo de verificación ya no encuentra, en todas las páginas en las que se vio por última vez, se marca como corregido. Un hallazgo que estaba corregido y reaparece vuelve a estar abierto.

Lo que usted hace: poner los cambios en producción, fusionando y desplegando el pull request, publicando la copia del tema o aplicando el paquete. Después, pida el escaneo de verificación: un administrador de su organización lo solicita en el portal del cliente, o usted se lo comunica a Validiscan por correo electrónico.

Tras el escaneo de verificación, Validiscan elabora el Remediation Evidence Package: un registro fechado de lo que se probó, lo que se cambió y lo que confirmó el escaneo de verificación. Se genera a partir del escaneo de referencia, del escaneo de verificación y de las revisiones manuales. Se entrega en PDF, DOCX y JSON dentro de un zip con sumas de comprobación SHA-256, e incluye un borrador de declaración de accesibilidad para su tienda, marcado como borrador para revisión jurídica. Un paquete terminado no cambia; una rectificación es una versión nueva. Usted lo descarga desde el portal del cliente.

Su declaración de alcance dice: «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.» También 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.»

Un proyecto cubre una tienda: un dominio y un tema. Incluye el escaneo de referencia, las revisiones manuales, las correcciones AUTO y ASSISTED entregadas de una de las tres formas descritas más arriba, un escaneo de verificación y el Remediation Evidence Package.

La protección contra regresiones es el último paso, es opcional y se factura cada mes. Validiscan vuelve a escanear su tienda cada semana y compara el resultado con la referencia verificada. Los problemas corregidos pueden reaparecer, por ejemplo tras una actualización del tema o de una app. Un problema que ha reaparecido vuelve a estar abierto.

Validiscan envía como máximo un correo electrónico por cada nuevo escaneo: cuando ese escaneo ha encontrado un problema corregido que ha reaparecido, un problema nuevo, un problema que ya no aparece o un cambio en las páginas cubiertas, y cuando no ha podido terminar. Un nuevo escaneo en el que no se da ninguno de estos casos no genera ningún correo, salvo que usted se lo haya pedido a Validiscan. El portal del cliente muestra cada nuevo escaneo en una cronología. Corregir lo que encuentra un nuevo escaneo no forma parte de la protección contra regresiones.